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 69497C61DF7 for ; Fri, 24 Nov 2023 10:06:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D61078D0063; Fri, 24 Nov 2023 05:06:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D104C6B054A; Fri, 24 Nov 2023 05:06:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C25E38D0063; Fri, 24 Nov 2023 05:06:40 -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 B3DBE6B0549 for ; Fri, 24 Nov 2023 05:06:40 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 80A64A113A for ; Fri, 24 Nov 2023 10:06:40 +0000 (UTC) X-FDA: 81492418560.08.0AB1215 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by imf17.hostedemail.com (Postfix) with ESMTP id 1366A40011 for ; Fri, 24 Nov 2023 10:06:36 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=h86bSbi7; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf17.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700820397; 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=dE8GrJ1krUh9N4/3x3iplrHfN4JEAup8XumDKHR5Cuk=; b=kYnFwqLYnCCySfY2Nn/XB5+MO8SxPRqs1s6wEcjg1DL0Ve+Q+xduWeI5yUTVdYU5Zhf+Ys HbgQ/k1V0S7DekdPoD64zTWZUkvj6HJbMJI7oUa51Be5mVWZZLgWD5kMnWUzOoFodGApVe nPgvCJizIXyUDYFtNv9EicWoeLdY75g= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=h86bSbi7; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf17.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700820397; a=rsa-sha256; cv=none; b=uQt7HUAJmLIndZoI6toppBfDKZ/UyRcr6APYhbWp6KiRMZMw2c2O6aCfSXFg6qv+7ya6j+ XmZ53kpEf2nKpgRv6ViKXmSbeE1KrTL4qrwFO+varYQSHBcvGK0s14i/Ozd93GhbuLajqV VAjoVoiD3RR2oN0uTotaRujFhlzqngw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1700820397; x=1732356397; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ohoDw7JZUTv1RjPou6a4xNAn3GHL7KxVPsE5YzKJdKk=; b=h86bSbi75TrR2qei1yWoTRc3hJmN/vXZXN+/7/A0oHNnyG3HYqhLQkyP DRjbCZfU7Uc9XrE70fftOsiunGa5mDJgLTZ+UCXywGTqNJaOvdY2OyjA3 LSrnHOQbLwQ9XOY+v+aylxXl9b+vRriCfKDD1UgT9udc3kUxNxOgzCFVS 35LpykN2ua7j51tAINvR7PdupKpXCspn38WigmeVjjQc1GcSK5LGyW1mD EgMfVsEGIUzsjluApWSCQ9J4oNxGPVl3a8N2NobySIARiZH8U8F125Twv XLyfPzhwzgYby4wkuzIG8y4Z2sLucj3Rmo1L73wu9Z0LERIdmqe6Iyi4w Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10902"; a="377430634" X-IronPort-AV: E=Sophos;i="6.04,223,1695711600"; d="scan'208";a="377430634" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Nov 2023 02:06:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10902"; a="1014863922" X-IronPort-AV: E=Sophos;i="6.04,223,1695711600"; d="scan'208";a="1014863922" Received: from dlemiech-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.59.78]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Nov 2023 02:06:29 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id 6460210A38A; Fri, 24 Nov 2023 13:06:27 +0300 (+03) Date: Fri, 24 Nov 2023 13:06:27 +0300 From: kirill.shutemov@linux.intel.com To: mhklinux@outlook.com 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: <20231124100627.avltdnuhminwuzax@box> References: <20231121212016.1154303-1-mhklinux@outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231121212016.1154303-1-mhklinux@outlook.com> X-Rspamd-Queue-Id: 1366A40011 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: tqp4kurnp5cx1e717a45ode76ff3w4ij X-HE-Tag: 1700820396-551823 X-HE-Meta: U2FsdGVkX18dIa6nDPd7oT/UsVf+L0k378ra3MWkSq9N79qARvqReQojybkCuq1sRUsUEhfWF3Iq541nrhQj6oAQBZgtlmFcrWPTBcF83sV+Or3UbaSDjrqLRYwtlOcZyPkwWCi0TvB4koBmpqViwO0AavCjkBicrDMuUuDAUCvfZmP+BzNyYvrgAKz0uaR/nxLo/DZ7h9m3yRHhRQJ6WDn/cNkT8SlyQ25BNfT9Q/Sn8DU7aat3oAsvQnoF+6ev40l4Au1E5eAFvvIK6Mv6d66syDhpULlxSrsU5uzrfSrlMwDR10EIL9VJNk18aqC3MCkdtVfr/GTXRkx8a/lCWrltfrjyGh5FkCp3o2ibl4NjmFs/8LZ9HUQHuPm3XPR+rtjHbXIQGRy7xFYG7gE3aCGQPzWvNoAP9lAOInPO5qfH5mYOZHyijlUx7ssW312KfmTnDFRWQM1QcMrjdLqMNacJ5V1QH+elSJm1VgiDI6NVwjynV2m1DCVzqadykWy450Lj7yFFNTICVnxTO+0nA/weB4rSoENoYpRFzTX/Soadr4IZxgqWo/NJnWznpyFiJgc41zqhAHwcmo9ePAhCvtuQO5RRObZLUsdrQ+aR1TAGNvajlvhfvDwU25Jn0F6ucKSn/5Rys3AdPR8yzV2h9dQJuBhMSP1vGl3HGaspKbBrwutb0iBQBLCO3MFpM0WLe4qx/v4GAX21gi62/eya6zez1JC+tIyA18tadD92ro+fvNPn8zVYyQZVpEJxH8Bf4W/xmhpbMnPG6YQo42JM2BLtZqkgOp7R4D7OLVDjmZcLFzJngnKvx2QYZA3fZ8FzItcwDKDSRazJ5uqTJguNnoGQcP8ODPsKPfTO5AO/aQNYY3+u14aW0cgFZd72spxVxenQNB2orYeRzUwa9nUwYr2YNJzsuB5TsKvmhmGoBjMTxjfhfAlu989Uszwm+TvL25EHIWxFMoK84W+qT0Z CA+dlTrF PxITgH8Q+LX/liB8G+BU5uEUXciNmBccItUkqWDaCuKDuWog7YO3I6yO+kt8dJ8RkdDxkJf4n+ViV9WHP+CTTYuNEPtxfXAuC8y4TIP94oguq5g9gxjDTqmB6yD0beBmIpuSO7Sll2IXXopreHaSWmeQ4jVCOjcMnj0lGMUf0PxjELDA= 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 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. > 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. -- Kiryl Shutsemau / Kirill A. Shutemov