Message ID | 20240105183025.225972-1-mhklinux@outlook.com (mailing list archive) |
---|---|
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 6A171C3DA6E for <linux-mm@archiver.kernel.org>; Fri, 5 Jan 2024 18:30:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 894CE6B0256; Fri, 5 Jan 2024 13:30:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 845636B0258; Fri, 5 Jan 2024 13:30:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E4E36B025F; Fri, 5 Jan 2024 13:30:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5D1866B0256 for <linux-mm@kvack.org>; Fri, 5 Jan 2024 13:30:44 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 28636140B40 for <linux-mm@kvack.org>; Fri, 5 Jan 2024 18:30:44 +0000 (UTC) X-FDA: 81646098408.26.446A686 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf26.hostedemail.com (Postfix) with ESMTP id EA45E14001C for <linux-mm@kvack.org>; Fri, 5 Jan 2024 18:30:40 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fEWr16F8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of mhkelley58@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=mhkelley58@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704479441; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=GhZC869aJnqNJACUr8BJ3n7gkdmfHBpgiLz8gKtgcrw=; b=pjdvFCn4XYoluKsuWSilE0B6+a979OK0IKELiEVIscFs2f08+pMu9ryKkUz6fnOODN2j4J xRHV7ftfqXkzC4iFM9FlSGacfuXW+CxQBjJ18PvVarEqmi2lR3278aKSm9x+yGN7C1HDz+ H2Ij3NPWvjZn4bAJ7oVEMvMucH5gb2Y= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fEWr16F8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of mhkelley58@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=mhkelley58@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704479441; a=rsa-sha256; cv=none; b=vswmNZccDE/SEq4ESbZvbq6NyiRHKZkhniT+OwXk5ECBW57/JOI8EG2ZnQGNdP2G2Yvm6S HQWChtcV6rCh6GT6w1Evb3MPIvtRTmFLUgDPiWNe5M8Q3UAmhNh6e3ebKrbG9cq9YreOAh VmVpmFmc/Z+Wk1vAxmtAfIFY4l661k4= Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-28ceef21be2so1322203a91.3 for <linux-mm@kvack.org>; Fri, 05 Jan 2024 10:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704479440; x=1705084240; darn=kvack.org; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=GhZC869aJnqNJACUr8BJ3n7gkdmfHBpgiLz8gKtgcrw=; b=fEWr16F8KXUgnHpb8nHRIy+1nwwgRY2yZUY7oTfx5HEY5Wz70Qy3MwknNSCKIswoXJ ikTCUnLef+oIEsP3gG+KIhRwbogKZqmBvC/vPMA4dj9N6zKIFpmHrLE+YiLJm80d8NJv uhfvTC186jXSWP+sbZ9PEV0dVDhZAXRl8DVebozz4wE2zTym8H88vyBQ7cfG/Y6cpKPi 0SS5svBmVo8UrpVqgXWCeYB0ElngBmqyk8eCORIW/BeSFvfHZCEsYllT7HZksDS24AFs yHjn6CnJvfA75N7HN34Qon8UkhlC7Gjtdik4jyDeuDh8o8BOrrDKxH0/pNdXq3voj+dW xEjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704479440; x=1705084240; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GhZC869aJnqNJACUr8BJ3n7gkdmfHBpgiLz8gKtgcrw=; b=sZB86+P2A4/sHR07vhKH/u4g18Dii3WsRz5bkGhouSEZB0JeI8gz/ejxwaYK5hjg8H PpilU5Fdjj3815H5e5OUWdpYydXudPB1l/Bu8cAT1M86QnwesolOvIkEt3iqFbVw1YOe SZyXFywMboDjWYr9gjNQTK+sw17knNCfZarapHXWJR5kphPUPHR0/1WAKuuCcBOFYSNd kUzfz20oAM1Wpz9A4YueOQHexK/vwBhfTgDLeBQlu2fgpMwuDM9D8kSQdTeXUUJNPXKl SGxWZTO9IwgMCjXBMXj36ZfzEfhx50IaZIsKMGas3yl+MPYW8n9vS/07SQdRsmwZod+o /yuQ== X-Gm-Message-State: AOJu0Yz1xzTiRydLr9BeBV45FVnpIJnqKmoZLPlV9CdMSZF4opMBrPhi 82WCfzTCvKbn7i72lGfJrtk= X-Google-Smtp-Source: AGHT+IHXiqb2zLOL212dF7sFCdw/skkZ7ndS0GC2Iw301HIGKXy9MO1ye5sBWak1F9zIaebZIH9sdw== X-Received: by 2002:a17:90a:51a2:b0:28c:76b:7cf7 with SMTP id u31-20020a17090a51a200b0028c076b7cf7mr2000773pjh.21.1704479439684; Fri, 05 Jan 2024 10:30:39 -0800 (PST) Received: from localhost.localdomain (c-73-254-87-52.hsd1.wa.comcast.net. [73.254.87.52]) by smtp.gmail.com with ESMTPSA id 23-20020a17090a195700b002868abc0e6dsm1687293pjh.11.2024.01.05.10.30.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 10:30:39 -0800 (PST) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: 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, wei.liu@kernel.org, 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: [PATCH v3 0/3] x86/hyperv: Mark CoCo VM pages not present when changing encrypted state Date: Fri, 5 Jan 2024 10:30:22 -0800 Message-Id: <20240105183025.225972-1-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 Reply-To: mhklinux@outlook.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: EA45E14001C X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: sbya3my1wun96tjjsusq3hmejirhysr8 X-HE-Tag: 1704479440-53017 X-HE-Meta: U2FsdGVkX1/KGIkAbfKfjWGfccKM//loxfsEipPYLQce65tHMrzXphiiQpm58JxDhRZZ4QeDn42TZQoUNxOmyZbZ6ulR/L6kfywLTrymrToKQUVFtvbWUbDjHukehvImsxfzI3YLQ2Z+k+lkbITY+pOXMrhUBqqnXylszfmBXpq2Vj6eks2t4sb4Jh1cOGfItIK3KqczR1jnhixdU6yi0XHXbzzLv6mpHr1/lbCYpdxQlqbdQZfY+3vI9TAW3QuBvMk+wcowZ0yTY+03CEi8Yae7hsyX664WBz8kDhEL1XG170UGCMB0G3BUvCOAzDUIdyK6307PfA5r8bp7P09Ra3XrSfkKpTkLrHlhxrn9iyI8gJ6AgSfvJhua1HdEWUTU4UJfjWasNE3W8XbkmJ2YOU3yL1oIjfAtnD3oLkfvxCZrNyLFiLz55FQL+NKhv6Uh4CaI3aTatPAAhrooO1W5gcJRARP+xO2RUDqwnNTpHLnjxozkEKH/JKFw029f0651ZpIotzWOuxAB3eukkAc6ZQLoUJnfXsUeg0Y3WPNr5KgjzOt32Fy2p/JqeGJLVYqLVz4MasW5NZq6edWq5PjjvZu3My/9B+g3x1AiPahiUZNoMpM56zAFAsvFOP8ohStTVoUhJHS2vL6aw5KgsnUMy6n2gKtoLkNSrGAvEDrwio817iwkh6OjTu4CrOxVWXgNMZwSeHcc9KRKMm2cUafGIKAVLvCHc3Spk+vUKyU5j88szYc/mi5icmdzIWE53TDSoslFqugFf9OBmsX2sPk6C/tjlRvWs1tBxZ/QKq8c5kA7sCCHWrd6LV3F/eFPaHHNpfQ+xEUKmAhtRtJO11raDk19DH0/Fzzs4DdMH45rCVxJKlPmLYAMF4S/Q6yaXVL4iUG4NHAst89iYjvA0G37r93Q+RGTTdTo5EIgUI4lNNkqZVAiEkECYvKZj7LM5jP22cxAEiVNaskMP3fnY69 zdQCpncd G8p4mR3/02vUGtxzHnZpHFyq3dYTOSAps3jV4fIZECURdRPmvDoaPNflvQDlkfcNymL9iKzZs5oaLq4xq7ARBIds/0uNDpxFiXHKv1X8AqB+VrNJWE0MoOi3WLsyzPgeffBQxsoJMV3XHQ9Iq3QLAqEsE4GUR6fzwI9t+QYaUJDBTHMZ/VmuKp9oYrf/EmvG+Jbrz4PmDWYnsaVsdAhyS7XaAc+ygnHOSrcbs 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
x86/hyperv: Mark CoCo VM pages not present when changing encrypted state
|
expand
|
From: Michael Kelley <mhklinux@outlook.com> 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. However, the kernel load_unaligned_zeropad() mechanism could cause a stray 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 paravisor, 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. 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. 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 implementation 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. 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. 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. Patch 1 handles implications of the hypervisor callbacks needing to do virt-to-phys translations on pages that are temporarily marked not present. Patch 2 makes the existing set_memory_p() function available for use in the hypervisor callbacks. Patch 3 is the core change that marks the transitioning pages as not present. This patch set is based on the linux-next20240103 code tree. Changes in v3: * Major rework and simplification per discussion above. 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] [1] https://lore.kernel.org/lkml/20231121212016.1154303-1-mhklinux@outlook.com/ 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() arch/x86/hyperv/ivm.c | 58 ++++++++++++++++++++++++++++--- arch/x86/include/asm/set_memory.h | 1 + arch/x86/mm/pat/set_memory.c | 25 +++++++------ 3 files changed, 70 insertions(+), 14 deletions(-)