Re: [RFC PATCH 08/21] KVM: TDX: Increase/decrease folio ref for huge pages

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Mon, 2025-06-30 at 19:13 +0800, Yan Zhao wrote:
> > > ok! Lets go f/g. Unless Yan objects.
> I'm ok with f/g. But I have two implementation specific questions:
> 
> 1. How to set the HWPoison bit in TDX?
> 2. Should we set this bit for non-guest-memfd pages (e.g. for S-EPT pages) ?

Argh, I guess we can keep the existing ref count based approach for the other
types of TDX owned pages?

> 
> TDX can't invoke memory_failure() on error of removing guest private pages or
> S-EPT pages, because holding write mmu_lock is regarded as in atomic context.
> As there's a mutex in memory_failure(),
> "BUG: sleeping function called from invalid context at kernel/locking/mutex.c"
> will be printed.
> 
> If TDX invokes memory_failure_queue() instead, looks guest_memfd can invoke
> memory_failure_queue_kick() to ensure HWPoison bit is set timely.
> But which component could invoke memory_failure_queue_kick() for S-EPT pages?
> KVM?

Hmm, it only has queue of 10 pages per-cpu. If something goes wrong in the TDX
module, I could see exceeding this during a zap operation. At which point, how
much have we really handled it?


But, at the risk of derailing the solution when we are close, some reflection
has made me question whether this is all misprioritized. We are trying to handle
a case where a TDX module bug may return an error when we try to release gmem
pages. For that, this solution is feeling way too complex.

If there is a TDX module bug, a simpler way to handle it would be to fix the
bug. In the meantime the kernel can take simpler, more drastic efforts to
reclaim the memory and ensure system stability.

In the host kexec patches we need to handle a kexec while the TDX module is
running. The solution is to simply wbinvd on each pCPU that might have entered
the TDX module. After that, barring no new SEAMCALLs that could dirty
memory, the pages are free to use by the next kernel. (at least on systems
without the partial write errata)

So for this we can do something similar. Have the arch/x86 side of TDX grow a
new tdx_buggy_shutdown(). Have it do an all-cpu IPI to kick CPUs out of
SEAMMODE, wbivnd, and set a "no more seamcalls" bool. Then any SEAMCALLs after
that will return a TDX_BUGGY_SHUTDOWN error, or similar. All TDs in the system
die. Zap/cleanup paths return success in the buggy shutdown case.

Does it fit? Or, can you guys argue that the failures here are actually non-
special cases that are worth more complex recovery? I remember we talked about
IOMMU patterns that are similar, but it seems like the remaining cases under
discussion are about TDX bugs.