Speaker
Description
To improve performance of CoCo VMs, there's active work on huge pages for guest_memfd. The first "backend" in the works for providing huge pages is HugeTLB.
Frank summarized interest in having devdax/ZONE_DEVICE memory as another backend [1] for guest_memfd.
If guest_memfd is to be the guest memory provider of KVM, it has to support (almost) any memory backend that can be configured in a memslot today through VMAs, going beyond memory backends to other things can be mmap()-ed, like perhaps MMIO though VFIO.
I would like to get ideas and feedback on how guest_memfd should be extended to support different backends.
Are flags what we really want to go with? Will we end up supporting many flags? Using HugeTLB as an example, flags/fields can encode use of HugeTLB, HugeTLB page sizes, but how would the HugeTLB mount be encoded? Should there be some way to encode size limits of the mount? Is that a required feature?
Could we perhaps reuse existing interfaces to communicate the memory config to guest_memfd? What if we hand fds (opened on specific mounts) where guest_memfd can grab config from? Should guest_memfd perhaps use pre-allocated memory from the fd?
[1] https://lore.kernel.org/all/CAPTztWajm_JLpp9BjRcX=h72r25ELrXeGkOXVachybBxLJGS=g@mail.gmail.com/