On Thu, Jun 20, 2024 at 05:08:37PM -0700, Sean Christopherson wrote: > On Thu, Jun 20, 2024, Rick Edgecombe wrote: > > Force TDX VMs to use the KVM_X86_QUIRK_SLOT_ZAP_ALL behavior. > > > > TDs cannot use the fast zapping operation to implement memslot deletion for > > a couple reasons: > > 1. KVM cannot zap TDX private PTEs and re-fault them without coordinating > > Uber nit, this isn't strictly true, for KVM's definition of "zap" (which is fuzzy > and overloaded). KVM _could_ zap and re-fault *leaf* PTEs, e.g. BLOCK+UNBLOCK. > It's specifically the full teardown and rebuild of the "fast zap" that doesn't > play nice, as the non-leaf S-EPT entries *must* be preserved due to how the TDX > module does is refcounting. Actually, slower zap all for TDX was also considered. e.g. 1) fully dropping of the leaf entries within the range of memslot 2) just blocking all other leaf entries But given current TDX MMU series does not provide block-only implementation, that proposal was aborted internally :) BTW, there's another proposal, not sure if you will consider it. We can still have users to control whether the quirk is enabled or not. (i.e. KVM does not enforce quirk disabling). If user does not disable the quirk for TDX, then kvm_mmu_zap_all_fast() will be called to invalidate all shared EPTs. Meanwhile, could we trigger kvm_gmem_invalidate*() in kvm_gmem_unbind() as well? Then, the private EPT will also be ensured to be zapped before memslot removal. The concern for this approach is that we need to do some similar invalidation stuffs when in future memslots besides gmem can also be mapped into private EPT.
