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. > > 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. Thanks, Alex
