Re: [PATCH] KVM: VMX: Flush shadow VMCS on emergency reboot

["Huang, Kai" <kai.huang@intel.com>]

On Fri, 2025-04-11 at 09:57 -0700, Sean Christopherson wrote:
> > > 
> > > On a very related topic, doesn't SPR+ now flush the VMCS caches on VMXOFF?  If
> > 
> > Actually this behavior is not publicly documented.
> 
> Well shoot.  That should probably be remedied.  Even if the behavior is guaranteed
> only on CPUs that support SEAM, _that_ detail should be documented.  I'm not
> holding my breath on Intel allowing third party code in SEAM, but the mode _is_
> documented in the SDM, and so IMO, the SDM should also document how things like
> clearing the VMCS cache are supposed to work when there are VMCSes that "untrusted"
> software may not be able to access.
> 
> > > that's going to be the architectural behavior going forward, will that behavior
> > > be enumerated to software?  Regardless of whether there's software enumeration,
> > > I would like to have the emergency disable path depend on that behavior.  In part
> > > to gain confidence that SEAM VMCSes won't screw over kdump, but also in light of
> > > this bug.
> > 
> > I don't understand how we can gain confidence that SEAM VMCSes won't screw
> > over kdump.
> 
> If KVM relies on VMXOFF to purge the VMCS cache, then it gives a measure of
> confidence that running TDX VMs won't leave behind SEAM VMCSes in the cache.  KVM
> can't easily clear SEAM VMCSs, but IIRC, the memory can be "forcefully" reclaimed
> by paving over it with MOVDIR64B, at which point having VMCS cache entries for
> the memory would be problematic.

I am not sure why we need to use MOVDIR64B to clear SEAM VMCSes in kdump? 
Regardless of whether we do that or not, IIUC there is no harm even we still
have SEAM VMCS cache entries in kdump:

They are associated with TDX private KeyID(s).  Sudden write back of them
doesn't matter because when reading them from /proc/vmcore they are garbage
anyway.  And IIUC no machine check (due to TD bit mismatch) will happen either.