On Tue, Jul 16, 2024, Jason Gunthorpe wrote:
On Tue, Jul 16, 2024 at 09:03:00AM -0700, Sean Christopherson wrote:
- To support huge pages, guest_memfd will take ownership of the hugepages, and provide interested parties (userspace, KVM, iommu) with pages to be used.
- guest_memfd will track usage of (sub)pages, for both private and shared memory
- Pages will be broken into smaller (probably 4K) chunks at creation time to simplify implementation (as opposed to splitting at runtime when private to shared conversion is requested by the guest)
FWIW, I doubt we'll ever release a version with mmap()+guest_memfd support that shatters pages at creation. I can see it being an intermediate step, e.g. to prove correctness and provide a bisection point, but shattering hugepages at creation would effectively make hugepage support useless.
Why? If the private memory retains its contiguity seperately but the struct pages are removed from the vmemmap, what is the downside?
Oooh, you're talking about shattering only the host userspace mappings. Now I understand why there was a bit of a disconnect, I was thinking you (hand-wavy everyone) were saying that KVM would immediately shatter its own mappings too.
As I understand it the point is to give a large contiguous range to the private world and use only 4k pages to give the hypervisor world access to limited amounts of the memory.
Is there a reason that not having the shared memory elevated to higher contiguity a deal breaker?
Nope. I'm sure someone will ask for it sooner than later, but definitely not a must have.