On Fri, 2023-09-15 at 10:50 -0700, Dave Hansen wrote: > 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. Right. AFAICT TDX cannot survive from S3 either. All TDX keys get lost when system enters S3. However I don't think TDX can be rebuilt after resume like SGX. Let me confirm with TDX guys on this. I think we can register syscore_ops->suspend for TDX, and refuse to suspend when TDX is enabled. This covers hibernate case too. In terms of how to check "TDX is enabled", ideally it's better to check whether TDX module is actually initialized, but the worst case is we can use platform_tdx_enabled(). (I need to think more on this) Hi Dave, Kirill, Rick, Is this solution overall acceptable?