"David Hildenbrand (Arm)" <[email protected]> writes: > On 6/15/26 19:39, Sean Christopherson wrote: >> On Mon, Jun 15, 2026, Alexandru Elisei wrote: >>> Hi, >>> >>> On Mon, Jun 15, 2026 at 11:43:14AM +0100, Alexandru Elisei wrote: >>>> Hi, >>>> >>>> >>>> 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. > > Right, and I raised in the guest_memfd call also the rough idea of Alexandru's > use case of having non-movable guest_memfd pages such that we can support use > cases where we can hopefully guarantee that a stage-2 mapping will not just > randomly go away. > >> >>>> 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.
More concretely, are y'all pointing towards a GUEST_MEMFD_FLAG_MIGRATABLE, which will set .migrate = kvm_gmem_migrate_folio, and for now, error out for CoCo VMs? >> >> 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. > > Right. Page migration for supporting ZONE_MOVABLE/CMA, compaction, memory > offlining, virtio-mem and possibly some collapse mechanism if we were to > support > THP of some sorts in guest_memfd would are all reasonable. > Background question: how would virtio-mem use migration in the host/guest_memfd? > As soon as we mix in access/lru semantics, we're going into the wrong > direction. > > Fortunately KSM is anon-only and not even worth a rant here :) > > > > -- > Cheers, > > David
