Re: [PATCH v2 4/4] KVM: guest_memfd: Stop returning struct page from PFN lookup

On Tue, Aug 18, 2026 at 09:15:55AM +0000, Ackerley Tng wrote:
> From: Sean Christopherson <[email protected]>
> 
> KVM currently expects guest_memfd PFN lookups to return a refcounted
> struct page, which callers hold across fault handling.
> 
> Holding a page reference across fault handling is problematic for
> guest_memfd. In-place memory conversions between confidential
> computing shared and private states inspect folio refcounts to ensure
> exclusive ownership by guest_memfd. A concurrent guest page fault
> taking a reference on the folio causes conversions to fail due to an
> elevated refcount.
Nit:
As this series is based on kvm-x86/next, where there's no in-place memory
conversion yet, kvm_gmem_get_pfn() does not hold shared filemap invalidate lock.

However, the benefit of dropping the folio reference immediately before
returning from the guest_memfd PFN lookup -- preventing conversion failures due
to an elevated refcount -- should be effective only if the reference is dropped
before releasing the shared filemap invalidate lock.

Do we need to make this info clear, since I think it's important? :)

> guest_memfd already notifies KVM of page invalidations, so callers
> within KVM only need to respect the MMU invalidation protocol to safely
> rely on guest_memfd for page presence.

Could we also explain why the lack of SetPageDirty() (and mark_page_accessed())
for a gmem page, due to NULL being passed to kvm_release_faultin_page(), is
harmless?

> Furthermore, removing struct page from the guest_memfd PFN lookup moves
> KVM closer toward supporting memory backends that are not backed by
> struct page.
> 
> Drop the folio reference immediately before returning from the
> guest_memfd PFN lookup, and stop returning the struct page pointer.
> 
> For ARM, initialize the local page pointer to NULL so that the shared
> cleanup path that releases fault-in pages safely no-ops for guest_memfd.
> 
> For x86, no additional changes are required in the MMU fault path
> because the page fault tracking structure is zero-initialized at the
> start of page fault handling, ensuring the refcounted page pointer is
> already NULL.
>
Otherwise, except for the missing hunk on arm, LGTM.

Tested-by: Yan Zhao <[email protected]>