Re: [PATCH v3 3/9] KVM: guest_memfd: implement folio migration for non-confidential VMs

["Garg, Shivank" <shivankg@amd.com>]

On Thu, 2026-09-10 at 12:05 +0200, David Hildenbrand (Arm) wrote:
> On 8/5/26 08:40, Shivank Garg wrote:
> > Implement kvm_gmem_migrate_folio() using filemap_migrate_folio() for
> > non-confidential VMs but don't enable it yet. guest_memfd mappings
> > are still marked unmovable, so MM never calls it.
> > 
> > MM invokes ->migrate_folio() callback with folios already locked and
> > acquires the invalidate lock afterwards. kvm_gmem_punch_hole() takes
> > the invalidate lock before locking folios during truncation, so
> > taking invalidate lock in migration callback can cause an ABBA-deadlock
> > situation. Use filemap_invalidate_trylock_shared() to avoid this.
> > 
> > A subsequent patch adds an opt-in flag to change the mapping to
> > movable and enable migration. Non-confidential VMs can use
> > host-side copy via folio_mc_copy(), whereas confidential VMs will
> > require firmware-assisted copying before they can opt in.
> > 
> > Signed-off-by: Shivank Garg <shivankg@amd.com>
> > ---
> >  virt/kvm/guest_memfd.c | 36 ++++++++++++++++++++++++++++++++++--
> >  1 file changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> > index 169f75f95433..583341d593c9 100644
> > --- a/virt/kvm/guest_memfd.c
> > +++ b/virt/kvm/guest_memfd.c
> > @@ -488,13 +488,45 @@ static struct file_operations kvm_gmem_fops = {
> >  	.fallocate	= kvm_gmem_fallocate,
> >  };
> >  
> > +#ifdef CONFIG_MIGRATION
> >  static int kvm_gmem_migrate_folio(struct address_space *mapping,
> >  				  struct folio *dst, struct folio *src,
> >  				  enum migrate_mode mode)
> >  {
> > -	WARN_ON_ONCE(1);
> > -	return -EINVAL;
> > +	struct inode *inode = mapping->host;
> > +	pgoff_t start, end;
> > +	int ret;
> > +
> > +	/*
> > +	 * Migration invokes ->migrate_folio() while holding the folio lock.
> > +	 * Use a non-blocking trylock to avoid inverting the lock order with
> > +	 * truncation, which takes the invalidate lock before locking the
> > +	 * folios.
> > +	 */
> > +	if (!filemap_invalidate_trylock_shared(mapping))
> > +		return -EAGAIN;
> > +
> > +	start = src->index;
> > +	end = start + folio_nr_pages(src);
> > +
> > +	kvm_gmem_invalidate_start(inode, start, end);
> > +
> > +	/*
> > +	 * For non-confidential guests the folio is host-readable, so
> > +	 * filemap_migrate_folio() can copy the contents itself via
> > +	 * folio_mc_copy().
> > +	 * For confidential guests, this would need firmware assistance.
> > +	 */
> 
> I think this is all more closely related to mapping_inaccessible().
> 
> If accessible, this is just trivially true that we can support this.
> 
> So I would not comment on what to do for confidential VMs for now, and limit it
> only to the shared-only case where pages are accessible.

Right, mapping_inaccessible is required for confidential memory to prevent
writes to memory in truncation path.

I agree that for shared guest-memfd only, I can defer splitting out AS_UNMOVABLE
and simply not do mapping_set_inaccessible.
This will further simplify this series.


Thanks,
Shivank