From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40599C48297 for ; Fri, 9 Feb 2024 15:51:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8DCE76B0075; Fri, 9 Feb 2024 10:51:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 88CC46B0078; Fri, 9 Feb 2024 10:51:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 706356B007D; Fri, 9 Feb 2024 10:51:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 626B26B0075 for ; Fri, 9 Feb 2024 10:51:20 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 12A92161040 for ; Fri, 9 Feb 2024 15:51:20 +0000 (UTC) X-FDA: 81772704720.27.6E81DBC Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04olkn2087.outbound.protection.outlook.com [40.92.46.87]) by imf06.hostedemail.com (Postfix) with ESMTP id 2CE05180028 for ; Fri, 9 Feb 2024 15:51:16 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=outlook.com header.s=selector1 header.b=ek8Aq4Ma; spf=pass (imf06.hostedemail.com: domain of mhklinux@outlook.com designates 40.92.46.87 as permitted sender) smtp.mailfrom=mhklinux@outlook.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=outlook.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1707493877; a=rsa-sha256; cv=pass; b=V2efGyzeStZapW+xoWHFNLvRB/Mloqtco0fGl7XiMjW9rORKJDx2lHFxaFMRlLNKPdChPM 39/5B1Jtr0o2ps2Ao7zicGRzGa4nrHpRG4DT117crEgB25Y9d11K51Ly1GMSqwveuXJV5H c3lOC7+01aNudIO7m7SO6eplsoeDmCY= ARC-Authentication-Results: i=2; imf06.hostedemail.com; dkim=pass header.d=outlook.com header.s=selector1 header.b=ek8Aq4Ma; spf=pass (imf06.hostedemail.com: domain of mhklinux@outlook.com designates 40.92.46.87 as permitted sender) smtp.mailfrom=mhklinux@outlook.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=outlook.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707493877; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=U8CHvNv7PFbrd0VVBGEfglDX5/lrXoLYbZn9aB6aDtI=; b=IFpmrD3pmXqKxf7IMGOwnLingGgw0LbdQcY2A83Ublw4OgZnwLtDYEvhx6DDDKct+8I2pf +mrzsM8lghNdbKzCtlMNARA9q6EZCUZrA3u0kp0Sf1C3EbJpX8NudGck9QpMR8r0nOY0Gq JFKYbaJ4cpySc3RgJmmuuGzJB6YOLIQ= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SMtoXlVZXQ56ua1Fqhik53+tvyUX3lQR5d7ksDdEHw6y2Mu5eev6nmwWUoHIOqmY+bxu/Abb4L2vTRkHnhpUqZPhPotIAfa+f/7Gki99AQuFoe0S58LMu4nqlxh2YyBv8ejv4ivA4BdvPhsuViG/h3uvkady5cp4gKDBXH2/pYF1YSq8jAzPyqgZUz6/yPLIAkKG06r5aeres+LZeiye+Ib4EEWoUV39fDNCXeXqg/SE+qdwtNymXZyfCb2CxnXsUZeuia0WOAoCDtAk8YQ6btEAHo+dSOcVro9oJojOq4sNbx2C44rigS8qEecVkirLc8uylyZiduNQoJ6Wu/1zWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=U8CHvNv7PFbrd0VVBGEfglDX5/lrXoLYbZn9aB6aDtI=; b=JM9mFRIiKRx4QMcMedgP1WXux+KePLf0UTg45oXDPSLRdkNt9oh3eIogfESZ1sN46OYfo9KRg6Ey1XpEX5+zT1P6bvJ6klT+Yp6UV+y3IrUQKmJBeJRSuR+s4fOYyGY3prjMFw6WksNP/AwUfAoY+XrSpecZQPOk0KIqkkKGGN1a/GVMB45XOUDTNyangROtOzVNjA9tM+Rpn19rNqo9s4UEB2ufXegUZzvNbsvDIYt/AT54U/ce2n9XUHMwCP5A+0pn42xiEbbLiyxsU83tgf7gXEDQQyO6RPbwVvwInH0OkC7QYhiY+G6RfB6yJ9Y88aYuh9sTjUeI2kgGYccvdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U8CHvNv7PFbrd0VVBGEfglDX5/lrXoLYbZn9aB6aDtI=; b=ek8Aq4Ma6We50+wR7W2bFCa4dMzf5TCYCoKnfr1D5oKC1+grWIQWdULY5VWjJ5WddP2K2KoWTtIysHR8a9LK9iyH8FBGovac8h8VxE3GTopt0H+iEZCs68fFHSXKVcL3XN8/hM5eAfjPbzPZQOFBLHBbjWVX/QUffkBwjbQhjHtz631RlpH1xfTM++dDE5OxR0ie8w7VzThTxRK9BgSSB3892QQNrv7AxsML+umD8zClE96cjTbVJ340A6TyRwWTC1t+HdXwFNircFVuahFBIpUXMJlQBsVhGEWXZNcNXyfZw8fgepR8DMwoyrWTxnVY2ackoNqrJGLSu+FZuXCmfA== Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23) by MW4PR02MB7492.namprd02.prod.outlook.com (2603:10b6:303:7c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7270.27; Fri, 9 Feb 2024 15:51:13 +0000 Received: from SN6PR02MB4157.namprd02.prod.outlook.com ([fe80::67a9:f3c0:f57b:86dd]) by SN6PR02MB4157.namprd02.prod.outlook.com ([fe80::67a9:f3c0:f57b:86dd%5]) with mapi id 15.20.7249.027; Fri, 9 Feb 2024 15:51:13 +0000 From: Michael Kelley To: "wei.liu@kernel.org" CC: "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "kirill.shutemov@linux.intel.com" , "haiyangz@microsoft.com" , "decui@microsoft.com" , "luto@kernel.org" , "peterz@infradead.org" , "akpm@linux-foundation.org" , "urezki@gmail.com" , "hch@infradead.org" , "lstoakes@gmail.com" , "thomas.lendacky@amd.com" , "ardb@kernel.org" , "jroedel@suse.de" , "seanjc@google.com" , "rick.p.edgecombe@intel.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "linux-kernel@vger.kernel.org" , "linux-coco@lists.linux.dev" , "linux-hyperv@vger.kernel.org" , "linux-mm@kvack.org" Subject: RE: [PATCH v4 0/3] x86/hyperv: Mark CoCo VM pages not present when changing encrypted state Thread-Topic: [PATCH v4 0/3] x86/hyperv: Mark CoCo VM pages not present when changing encrypted state Thread-Index: AQHaSCKexFAY/xZWtkOyLYyKvYn/6LECTKjA Date: Fri, 9 Feb 2024 15:51:12 +0000 Message-ID: References: <20240116022008.1023398-1-mhklinux@outlook.com> In-Reply-To: <20240116022008.1023398-1-mhklinux@outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [G0Ndzn12MV+32UH1fR6q8PazfioyiZB2] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|MW4PR02MB7492:EE_ x-ms-office365-filtering-correlation-id: 6b768536-7678-4862-e6c3-08dc2986f11f x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7tmkelpnU4exZliC2btPV8AbjsVP/vAqn6U8aCrOaj13oKcjhA5CsnoN35mtFXhkQA3ZyCyFbt85AZs/nGB/jV0p0e8pFRit2dXxcbav2b+5tV69B9WU+ivXgY4Rb4VxdEY/Qb4fdZsxXfKFFJv2Em9pskNEXBWjVg9DkU3Df4XxJZAYPmOBnc/KT339FFCOFSkekoTIvSSHqkluOF5YQvt7kI5JMbugIE2ienKf4vZgp+z2m7qu8+FqthQ+oUimIRnXwYmdVb9GMXB9eQ83aEtesHOhGTWB4FSGtv/JhXSLm17o1ov5MxAcRe9Hi4kyjIRlWeyBJfV17chay4Fkh9bY5gpcWzYeHA5DmYaeKybxS97YQRcmFebJjahxaQrgc+DIhfjqe9eWgRvdxhlUYfVvXr73yivytD56Vd1N6JaQ1jBEqJgDvu/cFnGBfOq9Q9WX5Gm9dObc/Z+pVfBY57mnqcHVe2VsdEgDO83kq36NDS1PgZYRJlqcab9Fe5yyRuvDORb8RXz0qvJs6CvTHQV6MBABP6Ul1w+b2/3F+3s= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?tKb2rB0KSVx8MNyWSPWc97epu7kltnzxCI32rOcTI7r0NqzV8rI7VKWqPNKt?= =?us-ascii?Q?Qojdq9Zj8jRILH43UbeD8Ki8ZyLTkzYGvgdMeWBRHR5ZI3jLEpi9so4rFG1r?= =?us-ascii?Q?xhthW+RZ3ZqunxD3vlV/hMc6LJpToSpkT2b2RAdZ0T7BHUHY5c69QfTVxyuf?= =?us-ascii?Q?RMsqeHAW7gcVjJceFlXx4r/wiuzoyjIj6ab4dR8Qb83L+yTkl3Jo5p8hJLKM?= =?us-ascii?Q?7VM1aqNJeEw+nXZG+w5tASb9YB26Z5204sG5I5kpxkamhExnmPhtuRcVDJJz?= =?us-ascii?Q?KyZRSZ6CItNYfRm43JqQOkkbEuZx64X7izsAtEyz6HR9ukLrqcdBZhlnyqeH?= =?us-ascii?Q?CI9ZSVmvwgAO7y61C2OtxRni/W8kWBPKr3EE9lw052SV/vNY+9UFRvtSFi6R?= =?us-ascii?Q?BH2pNe8khDV3/j8snR/LOeLakk/0V7mrXuM9JbQvk/RKaDBxszcw0phlqGPn?= =?us-ascii?Q?llnoDl8i4h1QT51UxJGt7X0dwf9UwJNMa9DUdYAm3jP+DjrWQGP409aRLYL4?= =?us-ascii?Q?jJpBXGTW50of+eh54034Unex9EQmZd9eXHqVVvWUjs/vF9XTXApwhLjwOhJ3?= =?us-ascii?Q?8o9/qtncij9J41DpxOwrh6MMITegWqu6s3UvmRa1ruzDVs7eveYzmPDnUj8z?= =?us-ascii?Q?7OBJdye4WWEyj0cH0KEFQ6LJPCqlsWnBVjGYopE/iZO/bwH33u/17pl4Sdqg?= =?us-ascii?Q?IsTYUBCUWLQNeeKlDE6bHuoBcvQMmDRs0xw/ZSJfRjjWASPK9rnbojVI+wrh?= =?us-ascii?Q?JuyRUSEnHmh6g3SqND4TM2w61NO2zRGSNLUApUFKXNb88y/PTIMhdnu3xfQO?= =?us-ascii?Q?d93VLCQU48j16/BhR8kJoUdqQdstDpdscErXQc9ZfwMc5CP47hvs8Mb4S4Dr?= =?us-ascii?Q?+Pl7ANx6a5KOZITHigsvTQrKkPV/4aWHGrlrfaKTGHSg52EPL6nO6s1hc/Sz?= =?us-ascii?Q?aKL4UbDVnEZi6WdxuD3SbDPGwQVD1XFleTPcugDy1tH1zU5Kbo/efVWsnNM9?= =?us-ascii?Q?KFCgkC5URT+xiQd0H3+Ta6qdhQrohdP1+g5rmeXsZWLcvsPKt4lel763MlJ3?= =?us-ascii?Q?7Z9LVD48qRz65HBvE3GAsltCwhlSGnY2X1r+pX0rKhpgkB/65/U1ai11kvFB?= =?us-ascii?Q?zBSPpC1GqN85+d/gpMdaGYAHNrzlRGakgovGFHCbtUn0pn2AIpBhgvU1RTD1?= =?us-ascii?Q?jUnWm4IuzkaE4gXhCg5Vqjn6LXCKFfCBTi0cr0pYSrBTCyqz8BaYZwWTeGg?= =?us-ascii?Q?=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 6b768536-7678-4862-e6c3-08dc2986f11f X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2024 15:51:12.7338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR02MB7492 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 2CE05180028 X-Stat-Signature: my1b3ze6c9c74jgec1r8zrso1jup9aau X-Rspam-User: X-HE-Tag: 1707493876-201160 X-HE-Meta: U2FsdGVkX191xYdxGGbkSgFHspj0oN4YippyL7TDXoBFq0FTM+rm8ySLw6AQbm8BjvE2IMFA9GuhbvCQtgTEEL2PgzYJOcURfrlvjwZcL/Qhf68COaHj80QZ/147aafrC6uWlhxY3zASfS3G7lZQVzwbUuXwdzeeIIIi1SCP4o33VShZBI7pzu0Dl2cp18V4j08G9hyRQi2mU06Rut0odaqpq2+LoSZxKQ9sjkif3lfnoWNuRWBXesnSxWwNAb47QM2eCmBgWx0ZokWy2/8Ou2l6jQe+tizD5fTFCq+3OvU5sj/IpvGKNIV+0GHx+jDFwX0CJxuNHbNe18PLBEsOLxll74OYPPVHEzHHYkKXk+iumHMANUWtcCWbHvIuoEn+YAjZ75SSncqFqXrmoRnHa+UMK4fH5pI1LdZ6rgWv4p5R02B95PJBsxm6wq+6c06p/V8mrxX1QjxiqvKGW8EQn2+xgbgeKSrfUJJztTZ/Kye1gNE6vV7LZg3fHJZFGzUitMjD+b4dWSfQUHckzSJYsJ5CtDKP8WsU2b5GeY/ZZuF9ED1fiAzq4fAQXxqOEtmC5uynYbU+uIpyazqRWDYkXDD7sI+8Z0Nf44C89Xjjz7+wXnynCWarJV3/2ze5YJHYC4QYFVobNAbIikj2d/ZIJzjUeunQOI8IDJJFFXtbGM8FHVhfSTcjlZq/Pcg123wzQbGw4/jNZogS18Y2Id0+oQA/kpaRx+Hxgfb1hJo+xMDZexynBgrK2ZHQ7lkoQeHPXp5ak7NOP2VvFW/jH9JOJoDGsNbPoQPHx7COVv8QoPMFxPuhLZmRWhodkWX2Fi/UAui4zyckEFLFjJLVkdZisoFQvuVSmXhzHw5KmqRjuGUbTSM+uiewQBzxLw8MZBNxuK1OCGltSgzW0jyXf2UmF4qMUwvRjWBrgTs4j0fl+Mb7M66utbEu0mHZnZREf3KCS9SfJ1yHg2iPQqMFgb9 sSmm5NtS 2kmVHsy8keCX2uNGh+TBEcI7XHwvGWOq+hQyzmlhdD4509yHlndshKh4GIswP0TfITi2LO92cb8FbdRhVnIDVIOULe6yykIEgGzDHK14oVqOfQxclLhskdGqT3NC6OuqPEXPICjiWjF5ux4y40U5kyTenNLiGVkyutyAuL0bcLPwp410C5KZkhbuKggk2hzQvLJ1SuiTOd46spYFFsYqHc/CMBtsH4O+g3BI8OcybcReIjxL5Jp97AD7X7yGDC8pBNLh3gYD5tvM4mwi4+JNblQkTLvzW4hwDbrX1hmndyYr/kUarBjv9HmIN55PNDXXqksHC8b8FpcQsSQCOdIcVy2lYCcOwtaAgk8r05XNiHwwvLbrZV2NraW1i0L6KJXYb5VxOXC2R7pzf070r4GVpEYPS5FzUpmXFAR+5YvJSxX9TLQDj97Vu81Is2oM4MxZJafQmE2idc1x0RCa+oDv+6MmCvmwUR6d7B2+lAYVBJIYCHeW8bFI07ufWgXRM6qeeo8WriBjPGixitaY7u+2s+3vMHT4+XibS6QQBoF4t1f0QszsNqd/7baFsvzQNmymtD93g3Q74w8WPB5lD0bwor6fxQo2cS4b37hDefXlMBR2pStjIs4/3JLbcPiD0nIHsiiHa X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: mhkelley58@gmail.com Sent: Monday, January 15,= 2024 6:20 PM >=20 > In a CoCo VM, when transitioning memory from encrypted to decrypted, or > vice versa, the caller of set_memory_encrypted() or set_memory_decrypted(= ) > is responsible for ensuring the memory isn't in use and isn't referenced > while the transition is in progress. The transition has multiple steps, > and the memory is in an inconsistent state until all steps are complete. > A reference while the state is inconsistent could result in an exception > that can't be cleanly fixed up. >=20 > However, the kernel load_unaligned_zeropad() mechanism could cause a stra= y > reference that can't be prevented by the caller of set_memory_encrypted() > or set_memory_decrypted(), so there's specific code to handle this case. > But a CoCo VM running on Hyper-V may be configured to run with a paraviso= r, > with the #VC or #VE exception routed to the paravisor. There's no > architectural way to forward the exceptions back to the guest kernel, and > in such a case, the load_unaligned_zeropad() specific code doesn't work. >=20 > To avoid this problem, mark pages as "not present" while a transition > is in progress. If load_unaligned_zeropad() causes a stray reference, a > normal page fault is generated instead of #VC or #VE, and the > page-fault-based fixup handlers for load_unaligned_zeropad() resolve the > reference. When the encrypted/decrypted transition is complete, mark the > pages as "present" again. >=20 > This version of the patch series marks transitioning pages "not present" > only when running as a Hyper-V guest with a paravisor. Previous > versions[1] marked transitioning pages "not present" regardless of the > hypervisor and regardless of whether a paravisor is in use. That more > general use had the benefit of decoupling the load_unaligned_zeropad() > fixup from CoCo VM #VE and #VC exception handling. But the implementatio= n > was problematic for SEV-SNP because the SEV-SNP hypervisor callbacks > require a valid virtual address, not a physical address like with TDX and > the Hyper-V paravisor. Marking the transitioning pages "not present" > causes the virtual address to not be valid, and the PVALIDATE > instruction in the SEV-SNP callback fails. Constructing a temporary > virtual address for this purpose is slower and adds complexity that > negates the benefits of the more general use. So this version narrows > the applicability of the approach to just where it is required > because of the #VC and #VE exceptions being routed to a paravisor. >=20 > The previous version minimized the TLB flushing done during page > transitions between encrypted and decrypted. Because this version > marks the pages "not present" in hypervisor specific callbacks and > not in __set_memory_enc_pgtable(), doing such optimization is more > difficult to coordinate. But the page transitions are not a hot path, > so this version eschews optimization of TLB flushing in favor of > simplicity. >=20 > Since this version no longer touches __set_memory_enc_pgtable(), > I've also removed patches that add comments about error handling > in that function. Rick Edgecombe has proposed patches to improve > that error handling, and I'll leave those comments to Rick's > patches. >=20 > Patch 1 handles implications of the hypervisor callbacks needing > to do virt-to-phys translations on pages that are temporarily > marked not present. >=20 > Patch 2 makes the existing set_memory_p() function available for > use in the hypervisor callbacks. >=20 > Patch 3 is the core change that marks the transitioning pages > as not present. >=20 > This patch set is based on the linux-next20240103 code tree. >=20 > Changes in v4: > * Patch 1: Updated comment in slow_virt_to_phys() to reduce the > likelihood of the comment becoming stale. The new comment > describes the requirement to work with leaf PTE not present, > but doesn't directly reference the CoCo hypervisor callbacks. > [Rick Edgecombe] > * Patch 1: Decomposed a complex line-wrapped statement into > multiple statements for ease of understanding. No functional > change compared with v3. [Kirill Shutemov] > * Patch 3: Fixed handling of memory allocation errors. [Rick > Edgecombe] >=20 > Changes in v3: > * Major rework and simplification per discussion above. >=20 > Changes in v2: > * Added Patches 3 and 4 to deal with the failure on SEV-SNP > [Tom Lendacky] > * Split the main change into two separate patches (Patch 5 and > Patch 6) to improve reviewability and to offer the option of > retaining both hypervisor callbacks. > * Patch 5 moves set_memory_p() out of an #ifdef CONFIG_X86_64 > so that the code builds correctly for 32-bit, even though it > is never executed for 32-bit [reported by kernel test robot] >=20 > [1] https://lore.kernel.org/lkml/20231121212016.1154303-1- > mhklinux@outlook.com/ >=20 > Michael Kelley (3): > x86/hyperv: Use slow_virt_to_phys() in page transition hypervisor > callback > x86/mm: Regularize set_memory_p() parameters and make non-static > x86/hyperv: Make encrypted/decrypted changes safe for > load_unaligned_zeropad() >=20 > arch/x86/hyperv/ivm.c | 65 ++++++++++++++++++++++++++++--- > arch/x86/include/asm/set_memory.h | 1 + > arch/x86/mm/pat/set_memory.c | 24 +++++++----- > 3 files changed, 75 insertions(+), 15 deletions(-) >=20 Wei -- Can this series go through the Hyper-V tree? It's mostly Hyper-V specific code, plus some comments and a minor tweak to a utility function in 'mm'. All comments on earlier versions have been addressed, and it would be good to get some mileage in linux-next before the 6.9 merge window. Michael