On 6/16/26 20:09, Ackerley Tng wrote: > "David Hildenbrand (Arm)" <[email protected]> writes: > >> On 6/15/26 19:39, Sean Christopherson wrote: >>> >>> +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. >> >>> > > 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?
Good question! As long as there is no nested-virt support (and virtio-mem support for coco still being in the making) that wouldn't apply, only ordinary memory hot(un)plug (incl CXL). -- Cheers, David
