This patchset is also available at:
https://github.com/amdese/linux/commits/snp-inplace-conversion-rfc1
and is based on top of the following patches plucked from Ackerley's
HugeTLBFS series[1], which add support for tracking/converting guest_memfd
pages between private/shared states so the same physical pages can be used
to handle both private/shared accesses by the guest or by userspace:
KVM: selftests: Update script to map shared memory from guest_memfd
KVM: selftests: Update private_mem_conversions_test to mmap guest_memfd
KVM: selftests: Add script to exercise private_mem_conversions_test
KVM: selftests: Test conversion flows for guest_memfd
KVM: selftests: Allow cleanup of ucall_pool from host
KVM: selftests: Refactor vm_mem_add to be more flexible
KVM: selftests: Test faulting with respect to GUEST_MEMFD_FLAG_INIT_PRIVATE
KVM: selftests: Test flag validity after guest_memfd supports conversions
KVM: guest_memfd: Add CAP KVM_CAP_GMEM_CONVERSION
KVM: Query guest_memfd for private/shared status
KVM: guest_memfd: Skip LRU for guest_memfd folios
KVM: guest_memfd: Introduce KVM_GMEM_CONVERT_SHARED/PRIVATE ioctls
KVM: selftests: Update guest_memfd_test for INIT_PRIVATE flag
KVM: guest_memfd: Introduce and use shareability to guard faulting
KVM: guest_memfd: Make guest mem use guest mem inodes instead of anonymous inodes
fs: Refactor to provide function that allocates a secure anonymous inode
"[RFC PATCH v2 00/51] 1G page support for guest_memfd"
https://lore.kernel.org/lkml/cover.1747264138.git.ackerleytng@xxxxxxxxxx/
which is in turn based on the following series[2] from Fuad which implements
the initial support for guest_memfd to manage shared memory and allow it to
be mmap()'d into userspace:
"[PATCH v12 00/18] KVM: Mapping guest_memfd backed memory at the host for software protected VMs"
https://lore.kernel.org/kvm/20250611133330.1514028-1-tabba@xxxxxxxxxx/
(One of the main goals of posting this series in it's current form is to
identify the common set of dependencies to enable in-place conversion
support for SEV-SNP, TDX, and pKVM, which have been coined "stage 2"
according to upstreaming plans discussed during guest_memfd bi-weekly calls
and summarized by David here[3] (Fuad's series[2] being "stage 1"),
so please feel free to chime in here if there's any feedback on whether
something like the above set of dependencies is a reasonable starting point
for "stage 2" and how best to handle setting up a common tree to track this
dependency.)