Re: [PATCH v3 00/12] KVM: SEV: Fix RMP #PF due to freeing in-use VMSA

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 07, 2026, Tom Lendacky wrote:
> On 6/30/26 17:25, Sean Christopherson wrote:
> > Rework KVM's handling of guest-provided (and always guest_memfd-backed) VMSAs
> > to forcefully reclaim VMSA pages when the pages are being freed from their
> > backing gmem instance, e.g. in response to PUNCH_HOLE.  In the worst case
> > scenario, marking the page SHARED in the RMP will fail due to the page being
> > IN_USE, ultimately leading to RMP #PF violations due to guest_memfd freeing
> > the memory back to the kernel while it's still assigned to a VM.
> > 
> > Note, the implementation nearly identical to that used by KVM for VMX's APIC
> > access page (which isn't guest controlled, but is migratable and whose PA is
> > shoved directly into a vCPU control structure).
> 
> Looks good. If you wanted, you could replace some of those quick
> mutex_lock()/mutex_unlock() and write_lock()/write_unlock() calls with
> scoped guards, e.g. in patch #8:
> 
> 	scoped_guard(write_lock, &kvm->mmu_lock)
> 		__kvm_mmu_zap_all_fast_front_half(kvm);

How do (KVM x86) people feel in general about scoped_guard()?  I love the "regular"
guard(), but for the most part I dislike scoped_guard(), as I find it (slightly)
harder to read than "raw" lock/unlock() calls.  I think because I mentally think
of anything like this:

	blah() {
		foo();
	}

as being a control-flow statement of some kind, i.e. code that is conditionally
executed.  So outside of flows where the benefits of the cleanup behavior are a
clear win, I prefer doing manual lock/unlock.