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 4579AC46467 for ; Wed, 11 Jan 2023 00:30:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A196B8E0002; Tue, 10 Jan 2023 19:30:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C9AA8E0001; Tue, 10 Jan 2023 19:30:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86A358E0002; Tue, 10 Jan 2023 19:30:53 -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 738668E0001 for ; Tue, 10 Jan 2023 19:30:53 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2CAAD1207DF for ; Wed, 11 Jan 2023 00:30:53 +0000 (UTC) X-FDA: 80340637986.20.AB90010 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf24.hostedemail.com (Postfix) with ESMTP id 20BB918000C for ; Wed, 11 Jan 2023 00:30:49 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="LMc07yG/"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf24.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673397051; 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=DRV04qFuwWY538QQp6xyTIKOuzp19tKQ9aasXuGLrSo=; b=8JudCuBZayfFxnEhDWi5/P8Unpy2Mv/PTlqFCqZ+PmU3s4Sh+34LMdHqYFlmG76MgGHGig 7GLE6O+EQYPiB8EYqjJje5hhenISxn9phPkFtHFXv61mPaNSh5fi1QVKYNHG6A12p2vNAY 671QBYFLxij4zegexvbY5bDqPqbGaJg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="LMc07yG/"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf24.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673397051; a=rsa-sha256; cv=none; b=2fjIbpO1mWXvCMwCUV5PwjzQyXONOist5WekgL6MfpqZXoRwSWcAPl2lok1QtJuPWKQNSq sG3m6HXdv/5Bu7Xr2RWlX0EUfo1TJd1ungC7fWpaUoAQOtn6yqydrG+FayLMdPY4nUYxY+ cD9fh0d0XQ1n+XbjXHFvSTsujYWhuQk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673397050; x=1704933050; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=JUviILzDclP6dIdqFUr0ki8G4FQJgb1JbwWGsrEAaus=; b=LMc07yG/YJhzwyOThCsYS9ilKNojxkC0WUzk1PKQBAtvT0w/14uxwOuC kYzZQ6wMk67MG+iO2ncTXk938I+UAs48I2lcO9b+s9B31YE4I892ncGGY WinKUCye1NUTdBQ+vGZqcDOp9uqhlvTXF/N1cdBNKIUuJ0HsiYi57DjQN gq7QOKy9kzSLDiHbKG12TnhI4BSH1c2NqNielEH0BzLuUzliuHfDEQ3wU 0LvcDBuyub9uApLo5svcvuEtthER7RgVcU9atnqeKAaVRVlG7aUEDbG0Z aVaSyGlWWvCkhtmfAzRs0W/HwTBvboVLtbvhNAI2DBnPWM/90/vwB5RSd A==; X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="303665217" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="303665217" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2023 16:30:48 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="725719077" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="725719077" Received: from svenka7-mobl1.amr.corp.intel.com (HELO [10.209.63.27]) ([10.209.63.27]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2023 16:30:47 -0800 Message-ID: Date: Tue, 10 Jan 2023 16:30:46 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v8 15/16] x86/virt/tdx: Flush cache in kexec() when TDX is enabled Content-Language: en-US To: "Huang, Kai" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: "Luck, Tony" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "kirill.shutemov@linux.intel.com" , "Christopherson,, Sean" , "Chatre, Reinette" , "pbonzini@redhat.com" , "linux-mm@kvack.org" , "Yamahata, Isaku" , "tglx@linutronix.de" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "peterz@infradead.org" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <6f959f494f0fb3dedfa963c3d6a0ce7f395b745d.camel@intel.com> <944ffd4b-3090-e068-a649-b9a84add8395@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 20BB918000C X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 1ftb7fmfsi4ju3d1yjzgxws5uz56i8zj X-HE-Tag: 1673397049-877594 X-HE-Meta: U2FsdGVkX1+NOm+YdamvqVVgAtJuOlZifEfm/Gcj+Ts8/+PBNXafd/kC/chAIosxVQIsAiihy5tUzpnKpoQkD33+W4q4+Xmn4mrxJFoZiTyItEy9uHyqoMD2lvPtfp9fR5G2Lu5j/hDV1gw6NYd6LRKhTfDwx9/0DXlTdx8oJYJey2zwNjqSnUzpf6HNfas9UxZFkrGH0kOeWXuOgp3e9iXRfoUyG4MIUhkpbdZf5FGDj3F2xQDM4MJ10P2p69c2gRMCg/rSZop0cl7JSotAT0fUFSQeQGaS6hnb47gxRHwyXqCebd3TrFxdF3V7UxSqoaUR17RVbpZVLr0noZyVa7za5LBZZvFyg/bZLYC4Ed7ryZnbfGPH9bJqKHUUdPf67/UZ3C3RjtdxedYBk5zjGrYshCD6JtD9CqJ10B4BiS21u7XJhPibzreAVtkEp1XR8QNC5q3Rx+v2lp36S4hKFDIIFprfbh/d+ZnXWJ8ksJfieHu99wTWss20WGqxcRxTDG+d9oq4C5zuGGCj0wTbfVzWBLgxN9YqKhxULBqkD5kTiHDeLsWMdP7Q+p6yJtpPeFLWGGVvMO2ixTMara+g56fciJIQLDmY6XE/KbfxGtp6jCazFoEYghL0NYoSphmJn7wIpYLu7ibxVFWDgrVs+QRAUwK5mRaL8JEoE8JcKP/r2DxPZjbIQWgfDswEIoiRdFU4byGHnys2fwXR98bmAbcsVjYubcJEulngqWEnFuiZtE/axUIJAbFGeLmSzIN/6y85BhAbbz8BYxi9jW1fFvpgGTbvVNlM/motctlFLiNrsqfD9fIMR+I95QF8n1gNQOnRKiF6uy70DgNearPEKp68HLQ06mFzkkucBEUrTvt1e0N786EfUURo9SPZ6oyw47eAEVrK5NGOmkuRHeK6Mw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000052, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 1/10/23 16:13, Huang, Kai wrote: > On Tue, 2023-01-10 at 07:27 -0800, Dave Hansen wrote: ... >> Think about it this way: kexec() is modifying persistent (across kexec) >> state to get the system ready for the new kernel. The caches are >> persistent state. Devices have persistent state. Memory state persists >> across kexec(). The memory integrity metadata persists. >> >> What persistent state does a conversion to KeyID-0 affect? It resets >> the integrity metadata and the memory contents. >> >> Kexec leaves memory contents in place and doesn't zero them, so memory >> contents don't matter. The integrity metadata also doesn't matter >> because the memory will be used as KeyID-0 and that KeyID doesn't read >> the integrity metadata. > > Right. So I guess we just need to call out the new kernel will use memory as > KeyID-0? Not even that. Say the new kernel wanted to use the memory as KeyID-3. What would it do? It would *ASSUME* that the memory *WASN'T* KeyID-3. It would convert it to KeyID-3. That conversion would work from *any* KeyID. So: KeyID-0: OK, because it has no integrity enforcement KeyID-1: OK, new kernel will convert the page KeyID-2: OK, new kernel will convert the page ... KeyID-$MAX: OK, new kernel will convert the page So, "OK" everywhere. Nothing to do... anywhere. Either I'm totally missing how this works, or you're desperately trying to make this more complicated than it is.