Re: [PATCH v3 10/12] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped

[Sean Christopherson <seanjc@google.com>]

On Wed, Jul 08, 2026, Ackerley Tng wrote:
> Sean Christopherson <seanjc@google.com> writes:
> 
> >
> > [...snip...]
> >
> > @@ -1902,6 +1905,7 @@ struct kvm_x86_ops {
> >  	void *(*alloc_apic_backing_page)(struct kvm_vcpu *vcpu);
> >  	int (*gmem_prepare)(struct kvm *kvm, kvm_pfn_t pfn, gfn_t gfn, int max_order);
> >  #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE
> > +	void (*gmem_invalidate_range)(struct kvm *kvm, struct kvm_gfn_range *range);
> >  	void (*gmem_reclaim_memory)(kvm_pfn_t start, kvm_pfn_t end);
> >  #endif
> 
> I suggested CONFIG_HAVE_KVM_ARCH_GMEM_RECLAIM_MEMORY before looking at
> this patch.
> 
> Considering this, it seems like gmem_invalidate_range is a true
> invalidation request and .gmem_reclaim_memory is too late for
> invalidation as you explained in the commit message of the renaming
> patch.
> 
> Perhaps the new .gmem_invalidate_range should take over
> CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE, and .gmem_reclaim_memory should
> use a new CONFIG_HAVE_KVM_ARCH_GMEM_RECLAIM_MEMORY?
> 
> Are they both invalidations in your opinion?

No, definitely not, I just didn't want to add another Kconfig.  And I still don't,
but I agree that lumping .gmem_reclaim_memory() into GMEM_INVALIDATE doesn't work,
because the behavior of sev_gmem_reclaim_memory() and sev_gmem_invalidate_range()
are completely unrelated.

> If we're clumping SNP configs together,
> CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE is also only enabled by SNP...

Yeah, but while I don't like a Kconfig explosion, I don't really want to end up
with CONFIG_HAVE_KVM_ARCH_GMEM_SNP_HOOKS either.

Oh, wait, isn't CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE going away?  I was going to say
we could bundle .prepare() and .reclaim() together, because conceptually they are
two bookends for updating out-of-band metadata, but that doesn't make a whole lot
of sense if .prepare() is going to disappear.