Re: [PATCH] KVM: SEV: Don't return a still-assigned gmem page to the host

[Hyunwoo Kim <imv4bel@gmail.com>]

On Thu, Jun 11, 2026 at 10:32:34AM -0700, Sean Christopherson wrote:
> On Fri, Jun 12, 2026, Hyunwoo Kim wrote:
> > On Thu, Jun 11, 2026 at 08:23:00AM -0700, Sean Christopherson wrote:
> > > On Thu, Jun 11, 2026, Hyunwoo Kim wrote:
> > > > > > To handle this properly, the folio would need to be taken off the LRU
> > > > > > before leaking, with something like folio_isolate_lru(), but that is
> > > > > > mm-internal and does not look usable from KVM. How should we proceed?
> > > > > > Please let me know if I am missing something.
> > > > > 
> > > > > I'm inclined to do nothing.  rmp_make_shared() should only fail in this case if
> > > > > there's a fatal bug somewhere, no?  Either that or do BUG_ON(), because at some
> > > > > point these types of errors are simply unrecoverable.
> > > > 
> > > > A guest can make a gmem page a VMSA via AP creation,
> > > 
> > > Ugh, the bane of my existence.  Can we kill off that feature yet?  I'm only half
> > > joking.  Not even half.
> > > 
> > > > and if that gfn is then hole-punched, a page that is still assigned to the
> > > > guest is returned to the host in sev_gmem_invalidate(), which looked like it
> > > > could lead to a host RMP PF, so I sent the patch.
> > > 
> > > Yeah, I suspect you're right.  But leaking the page doesn't fix the underlying
> > > problem, which is that it's possible to free a page that's being used as a VMSA.
> > > 
> > > We can't simply pin the page, because IIUC ->free_folio() is called when the page
> > > is removed from the filemap, not when the folio/page is free back to the allocator.
> 
> ...
> 
> > > The right way to handle this is to treat the VMSA "mapping" like an MMU mapping.
> > > I.e. this is fundamentally the same mess we have to solve in order to not pin
> > > pages that are mapped into L2 via vmcs01/vmcb02 for nVMX/nSVM.
> > > 
> > > Something like this, sans the actually handling of the request.  The simple way
> > > to handle the request would be to invalidate control.vmsa_pa if snp_has_guest_vmsa
> > > is true, and then redo the mapping part of sev_snp_init_protected_guest_state().
> > 
> > Understood. This looks like a fairly large change, at least for me,
> 
> Heh, definitely not just for you, it'll be a large, painful change for anyone :-)
> 
> > so would you be able to handle the patch?
> 
> Yeah, I'll work with Mike and others to get a fix landed.  Thanks much for the
> bug report!

OK. Thank you for the review :)