On Mon, Jun 15, 2026, Alexandru Elisei wrote: > Hi, > > On Mon, Jun 15, 2026 at 11:43:14AM +0100, Alexandru Elisei wrote: > > Hi, > > > > On Thu, Jun 11, 2026 at 01:05:07PM +0000, Shivank Garg wrote: > > > guest_memfd folios are currently marked unmovable, so the kernel cannot > > > perform NUMA-balancing, memory compaction, 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 so > > > __migrate_folio() skips the host-side folio_mc_copy(). > > > > I always thought that one of the nice things about using guest_memfd as a > > memory backend, as opposed to host userspace mappings, is that the host > > cannot unmap VM memory because of KSM, automatic NUMA balancing, hugepage > > collapse, compaction, etc, acting on the host userspace mapping of the > > VM memory, and outside of the VMM's or KVM's control.
+1000. It's not just "nice to have", it's a core design principle of guest_memfd. > > I think it would be useful to preserve this behaviour, even in the absence > > of confidential VMs (i.e, guest_memfd file descriptor created with > > GUEST_MEMFD_FLAG_MMAP). > > Just to be clear, I was thinking that it might be useful for both > behaviours to exist (migratable and non-migratable) for non-confidential > VMs, and allow KVM or userspace to decide which they prefer for a > guest_memfd. For the purposes of this discussion, we should separate the physical act of migrating pages from the features that trigger migration. As I said in last week's guest-memfd call, I am a-ok with supporting page migration as a mechanism, but I am dead set against supporting NUMA balancing, KSM, LRU-based swap/reclaim, and anything else that goes against the goal of guest-first memory. If userspace wants mm/ functionality, then use anon, memfd, hugetlb, shmem, etc. Shivank, what's the immediate motivation for this series?
