Re: [PATCH v2 4/9] KVM: Rework .gmem_invalidate() into .gmem_free_folio()

[Sean Christopherson <seanjc@google.com>]

On Mon, Jun 29, 2026, Ackerley Tng wrote:
> Sean Christopherson <seanjc@google.com> writes:
> 
> > On Mon, Jun 29, 2026, Ackerley Tng wrote:
> >> Sean Christopherson <seanjc@google.com> writes:
> >>
> >> >
> >> > [...snip...]
> >> >
> >> >
> >> > -void sev_gmem_invalidate(kvm_pfn_t start, kvm_pfn_t end)
> >> > +void sev_gmem_free_folio(struct folio *folio)
> >> >  {
> >> > +	kvm_pfn_t start = page_to_pfn(folio_page(folio, 0));
> >> > +	kvm_pfn_t end = start + (1ul << folio_order(folio));
> >> >  	kvm_pfn_t pfn;
> >> >
> >> >  	if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP))
> >>
> >> I thought we intended to draw the line such that the platforms don't
> >> reference folios, and so this function should be parametrized by pfn.
> >>
> >> I think we should still stick with
> >>
> >>   .free_folio = kvm_gmem_free_folio
> >>
> >> and kvm_gmem_free_folio() translates the folio to pfns and calls the
> >> arch function, named something like .gmem_LIFECYCLE_ACTION_pfn_range.
> >>
> >> Now for LIFECYCLE_ACTION, one way to think of it is that this should
> >> represent the point in the lifecycle of guest_memfd memory where the
> >> memory is removed from guest's private use, so perhaps "host_reclaim"?
> >
> > kvm_arch_gmem_reclaim_memory()?  I don't want to include "host", because the
> > "reclaim" may or may not be host initiated.  I don't want to use "pfn_range"
> > because it's too close to "gfn_range".
> >
> 
> kvm_arch_gmem_reclaim_memory() is good. It'll take PFNs pfn_start and
> pfn_end? 

Yep, I'll just do a pure rename.