[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52e9ae7e-2e08-5341-99f7-b68eb62974df@intel.com>
Date: Fri, 15 Sep 2023 10:50:00 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Huang, Kai" <kai.huang@...el.com>
Cc: "Raj, Ashok" <ashok.raj@...el.com>,
"david@...hat.com" <david@...hat.com>,
"bagasdotme@...il.com" <bagasdotme@...il.com>,
"Luck, Tony" <tony.luck@...el.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>,
"nik.borisov@...e.com" <nik.borisov@...e.com>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"hpa@...or.com" <hpa@...or.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"Shahar, Sagi" <sagis@...gle.com>,
"imammedo@...hat.com" <imammedo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>, "Gao, Chao" <chao.gao@...el.com>,
"Brown, Len" <len.brown@...el.com>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Huang, Ying" <ying.huang@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v13 17/22] x86/kexec: Flush cache of TDX private memory
On 9/15/23 10:43, Edgecombe, Rick P wrote:
> On Sat, 2023-08-26 at 00:14 +1200, Kai Huang wrote:
>> There are two problems in terms of using kexec() to boot to a new
>> kernel when the old kernel has enabled TDX: 1) Part of the memory
>> pages are still TDX private pages; 2) There might be dirty
>> cachelines associated with TDX private pages.
> Does TDX support hibernate?
No.
There's a whole bunch of volatile state that's generated inside the CPU
and never leaves the CPU, like the ephemeral key that protects TDX
module memory.
SGX, for instance, never even supported suspend, IIRC. Enclaves just
die and have to be rebuilt.
Powered by blists - more mailing lists