Re: [PATCH v3 0/9] KVM: guest_memfd: folio migration for non-confidential VMs
"Garg, Shivank" <[email protected]>
| Newsgroups | org.kernel.vger.linux-doc,dev.linux.lists.linux-coco,org.kernel.vger.kvm,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 2026-08-05 at 06:40 +0000, Shivank Garg wrote: > guest_memfd folios are currently always marked unmovable, so the kernel cannot > perform memory compaction, offlining, etc. This is unavoidable for > confidential VMs (SEV-SNP, TDX), since memory is encrypted and copying it > needs firmware assistance. However, for non-confidential VMs (like > Firecracker), we can migrate the folios. > > This series enables folio migration for non-confidential guest_memfd and > also lays the groundwork for migrating confidential guest_memfd later. > Once firmware-assisted copying support is available, those VMs can be > made movable, the confidential folio content can be copied separately, > and the destination folio marked with FOLIO_CONTENT_COPIED[4] so > __migrate_folio() skips the host-side folio_mc_copy(). > > Testing > ------- > Host: 7.2-rc6+(c21bb419386) + this, AMD EPYC ZEN 3, 2 NUMA nodes > > - KVM selftest: allocate folios on node 0, migrate them to node 1 and > back and verify resulting NUMA node and the folio contents at each > step. > > - Firecracker [1]: booted a microVM backed by guest_memfd. While the > guest was running, forced host-side migration of its folios via > migratepages(8) and explicit move_pages(2) of guest_memfd > pages. Verify with /proc/firecracker_pid/numa_maps. > > Notes > ----- > - Sashiko pointed out a pre-existing ABBA deadlock between > kvm_gmem_error_folio() and truncation. It's being addressed separately > by Hao Zhang. [2][3] > > [1] https://github.com/firecracker-microvm/firecracker/tree/feature/secret-hiding > In builder.rs, add GUEST_MEMFD_FLAG_MIGRATABLE to bit-2 and pass it instead > of GUEST_MEMFD_FLAG_NO_DIRECT_MAP to vm.create_guest_memfd(). > [2] https://lore.kernel.org/all/[email protected]/ > [3] https://sashiko.dev/#/patchset/20260611-shivank-gmem-migrate-v1-0-2d266bfc6f95%40amd.com > [4] https://lore.kernel.org/all/[email protected] > > Signed-off-by: Shivank Garg <[email protected]> > --- > Changes in v3: > - Fix unbalanced mmu_invalidate_in_progress count unbinding dying guest_memfd. (Sashiko) > - Fix maxnode handling in xapic_ipi_test selftest. > - Add GUEST_MEMFD_FLAG_MIGRATABLE documentation > - Replace open-coded sizeof() * 8 calculation with BITS_PER_TYPE() > - Add get_numa_mem_nodes() and use MPOL_F_MEMS_ALLOWED for allowed NUMA ndoes > instead of hardcoded NUMA node IDs. (Sashiko) > - Extend migration selftest to verify rejection without MIGRATABLE flag and > move repeated checks into common helpers. > - Drop RFC tag. > - Link to v2: https://lore.kernel.org/r/[email protected] > > Changes in v2: > - Make folio migration opt-in through GUEST_MEMFD_FLAG_MIGRATABLE, > preserving unmovable behavior if userspace don't explictly ask. (Alexandru, David, Sean) > - Add kvm_arch_supports_gmem_migration() so arch can control whether > GUEST_MEMFD_FLAG_MIGRATABLE is advertised. > - Allocate movable folios with GFP_HIGHUSER_MOVABLE. (David) > - Keep guest_memfd unevictable. (David, Sashiko, Sean) > - Split migrate_folio() implementation and enablement as separate patches. > - Update selftest with new flag. > - Link to v1: https://lore.kernel.org/r/[email protected] > > --- > Shivank Garg (9): > KVM: guest_memfd: take the invalidate lock when unbinding a dying file > mm: split AS_UNMOVABLE back out of AS_INACCESSIBLE > KVM: guest_memfd: implement folio migration for non-confidential VMs > KVM: guest_memfd: add GUEST_MEMFD_FLAG_MIGRATABLE > KVM: selftests: fix maxnode arguments in xapic_ipi_test > KVM: selftests: use BITS_PER_TYPE() for NUMA masks > KVM: selftests: add get_numa_mem_nodes() > KVM: selftests: use allowed NUMA nodes in guest_memfd_test > KVM: selftests: exercise guest_memfd folio migration > > Should I spin the independent patches out of this series for next cycle? Patch 1 is Sashiko reported fix and patches 5-8 are selftest fixes and cleanups. Migration patches can wait until its setting design discussion is settled. Thanks, Shivank