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 16ED5C4167B for ; Wed, 29 Nov 2023 15:10:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2A3C6B03B7; Wed, 29 Nov 2023 10:10:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A015B6B03BA; Wed, 29 Nov 2023 10:10:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A33C6B03BB; Wed, 29 Nov 2023 10:10:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 79FF96B03B7 for ; Wed, 29 Nov 2023 10:10:27 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 54AD9A0523 for ; Wed, 29 Nov 2023 15:10:27 +0000 (UTC) X-FDA: 81511328094.04.38A7D7A Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by imf16.hostedemail.com (Postfix) with ESMTP id 4B12C180019 for ; Wed, 29 Nov 2023 15:10:24 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kUm9hCLm; spf=none (imf16.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.13) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701270624; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=btN5tbam3yqIPjlfWdTIz2dHUDvBepULrUMXX0YMLuQ=; b=I7+x7LE5/ZT1hBk+hG5jDk67h9MJtyHe0Pt/nD3NqIqXt0qd6+uq7lrwYfQQYpSdwuN/br zIfToMZt86BKnkzSX/Jd9A4RDHPotvcDCecNpu2CSjVZTcTJmyG4aeIf/vnTdK6XJAaK0Z TiX+7WlHEFy8WGIdstI8ickTRvGd8PU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kUm9hCLm; spf=none (imf16.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.13) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701270624; a=rsa-sha256; cv=none; b=bOIYlJ9MRHnbkoym2yTwK0v2jsS1Ym7g7wyAvhcwdrbxtMo0eVP1Pr6zuHdfpZF/4GImYW xp85EPUNEMnhxamdefBTGvSfed1yap6ftgeMZvWpsd/+gUrdlPFWV3/DbkLpbk9QZ4b1Zh F3XilH85nqwjxiKuHAbF+F5V5rMtsQU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701270625; x=1732806625; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=+WmXrJbd+4V27ux01qGWHb6jKBIycuX+25UjSdydb/I=; b=kUm9hCLmucDJhT2YLngKEPLTjaUPdQEsOrrcDKuSV/1ztDfEJe72DxCL kXSbIqZ13GvBiCHIR89OsQ4CSHYAMJX60FJ0yYMEgQOxFdjLxjbckSo5j y3NgtlLlvd4B3l7M4F3nKQOWMlweaf94F1T4EvBsKoeDNisRYA+ncNhxs W0rCqld9WhsCTHxV9eGBN1o08NuAhPJT1Pll1aueh6fau+8kinlL8D45l oc6wDWSts1yNu7Wbk4z1brLIlVxtgTiTaoKUntOKF+s9gLW/e1pGATNaq wjdaZcJgzP2k3NgGuFA3Vp1ZM3+11+FauTW1Dk4VpuCC7hG7qXPqIc+rH w==; X-IronPort-AV: E=McAfee;i="6600,9927,10909"; a="162825" X-IronPort-AV: E=Sophos;i="6.04,235,1695711600"; d="scan'208";a="162825" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2023 07:10:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10909"; a="1016292536" X-IronPort-AV: E=Sophos;i="6.04,235,1695711600"; d="scan'208";a="1016292536" Received: from padamowi-mobl1.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.60.113]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2023 07:10:16 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id E10D010A424; Wed, 29 Nov 2023 18:10:12 +0300 (+03) Date: Wed, 29 Nov 2023 18:10:12 +0300 From: "kirill.shutemov@linux.intel.com" To: Michael Kelley Cc: "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "kys@microsoft.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: Re: [PATCH v2 0/8] x86/coco: Mark CoCo VM pages not present when changing encrypted state Message-ID: <20231129151012.4un33hvk4nrsicou@box> References: <20231121212016.1154303-1-mhklinux@outlook.com> <20231124100627.avltdnuhminwuzax@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4B12C180019 X-Rspam-User: X-Stat-Signature: r5zobp1kbeimo453637cijzi36rm13r8 X-Rspamd-Server: rspam01 X-HE-Tag: 1701270624-821844 X-HE-Meta: U2FsdGVkX1+3z9jaywKG8z7rUHTFtkkpRQGap2U4f3LaLDHTLwcPXyf5LIT+zbi7Rz4jDeYL4La4ANBINjcn3kPIjbJDfz5nhdxcAu8cdzFX346ZuJcm/ZMAQHfep/qSkVAQ+Uc7VP1HPqPeVjWCh7RaRa3PWZ6fpQPoWWNMixq76sqUXKuxuUk98j/CLItz1HemX+7VePWXLPP/0y5YFL/OeO8CFFmuye2w8H/SNXO3KAKGaZulEUHK3fHNh8xGNCCz6y78sCYZdOKHxPyXtLZnzxACoWK6Y7CdH/cOhyKZGqnI9vCXpNvtHvMAA/5TJOnbs5ekwLNczLV4DtBjoUxcxi9Nuk82u7jnqjqmc/FECrlqiLXPY8gftR3hPyQ1ow7WWszFivJMKf9H1MY/xvv60TLOEUdPtrA67MRnuB12H8Bz0wt/u9s1uKUkfQvVOKHyabNjlysLYwiGJDTZZnAq9LGM6wsC87+m7HAha726InK4dCGyzIRj1DvhC/KPwK+03e7cB9bdXGNZVzFq2Ha5qlKnrOK2FkX+1SsMvG2Us5C4CPNizwZUSytjhm4g+nmJI3lEX8u++XS1v6X2kMtTMQGVHbnMyODYLad0QICNa7k1pl8Dn0bJP9sTXPwMz8Z6Z7pkwQndg8j1m/vrDUutYaoOe3SZ6ggU7XjXsjtzewNExfNOPg4Zl4QVmb8e0KLqNi9a7iEWvdWoNwovg/0zgDh5iotsy45mA9whmmTALSWlS0xA/bS2ab37gUfBb0J9pU/HPLmQOGSHq2mYIwQhNdZtG73gV+xwpPrWLvgZhnGXUVRlZOygfB+JqLceuBXm27jD81sR4Dw8l/AYNTavYFLFtYQjCfmLZVxhXZlmMmRfsSz+CB6wDWkNvmZhCKMicYV4j6iZZMj4DtxJ7Il2pLtb7B/ANmbTm7SeYPmVmmELyRqAUuRPqSMy0MIqYD8l+nB07tWAzfpEjVr oQd0jnTb sA8lzxHXZVkbTYjWrMMbdKhH8IPq7pc+sEfheYpXiqcophrH2klR+mkTf2a90RAbpH7N3bFNjJaVTfbyKJ72qUVidNjarfsOXFBnGu1ahVHDxtEtTO9M4DuyXmsclACzNlcdcuSaJx7Z+FraOidOvTc7zpKs6SLLVHXgrrOU5jv9uC0Rs2pr9STTTi3SEb8HRTm2KgCr2erxYyUA9gdqojvBNEVr5ElUwMHpTJCYPEHGJ2bA438jZYs1KOg== 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: On Tue, Nov 28, 2023 at 07:12:33PM +0000, Michael Kelley wrote: > From: kirill.shutemov@linux.intel.com Sent: Friday, November 24, 2023 2:06 AM > > > > On Tue, Nov 21, 2023 at 01:20:08PM -0800, mhkelley58@gmail.com wrote: > > > From: Michael Kelley > > > > > > In a CoCo VM when a page transitions from encrypted to decrypted, or vice > > > versa, attributes in the PTE must be updated *and* the hypervisor must > > > be notified of the change. > > > > Strictly speaking it is not true for TDX. Conversion to shared can be > > implicit: set shared bit and touch the page will do the conversion. MapGPA > > is optional. > > Interesting. Given that, is there a reason to use the explicit > hypervisor callbacks in for private->shared transitions in > __set_mem_enc_pgtable()? It probably doesn't have direct relevance > to this patch series, but I'm just trying to understand the tradeoffs of > the implicit vs. explicit approach. And am I correct that > shared->private transitions must use the explicit approach? It must be explicit in sense, that the memory has to be accepted before use. MapGPA() is still optional. I don't like this implicit tricks. I spent a lot of time debugging an issue that was obscured by this semantics. But I think it is going to say :/ > > > Because there are two separate steps, there's > > > a window where the settings are inconsistent. Normally the code that > > > initiates the transition (via set_memory_decrypted() or > > > set_memory_encrypted()) ensures that the memory is not being accessed > > > during a transition, so the window of inconsistency is not a problem. > > > However, the load_unaligned_zeropad() function can read arbitrary memory > > > pages at arbitrary times, which could read a transitioning page during > > > the window. In such a case, CoCo VM specific exceptions are taken > > > (depending on the CoCo architecture in use). Current code in those > > > exception handlers recovers and does "fixup" on the result returned by > > > load_unaligned_zeropad(). Unfortunately, this exception handling can't > > > work in paravisor scenarios (TDX Paritioning and SEV-SNP in vTOM mode) > > > if the exceptions are routed to the paravisor. The paravisor can't > > > do load_unaligned_zeropad() fixup, so the exceptions would need to > > > be forwarded from the paravisor to the Linux guest, but there are > > > no architectural specs for how to do that. > > > > Hm. Can't we inject #PF (or #GP) into L2 if #VE/#VC handler in L1 sees > > cross-page access to shared memory while no fixup entry for the page in > > L1. It would give L2 chance to handle the situation in a transparent way. > > > > Maybe I miss something, I donno. > > I'm recounting what the Hyper-V paravisor folks say without knowing all the > details. :-( But it seems like any kind of forwarding scheme needs to be a > well-defined contract that would work for both TDX and SEV-SNP. The > paravisor in L1 might or might not be Linux-based, so the contract must be OS > independent. And the L2 guest might or might not be Linux, so there's > potential for some other kind of error to be confused with a Linux > load_unaligned_zeropad() reference. Okay, fair enough. I have hard time reasoning if it is okay for L2 which is not Linux. -- Kiryl Shutsemau / Kirill A. Shutemov