Gregory Price <[email protected]> writes:
> guest_memfd allocates its folios through a per-inode shared mempolicy.
>
> Today that policy can only be set after the fact, with mbind() on a host
> mmap of the fd. That requires the fd to be mappable, and it cannot reach
> folios that are only ever guest-faulted. Neither holds for a
> non-mappable (confidential) guest_memfd.
>
> Add GUEST_MEMFD_FLAG_BIND_NODE and a node field to struct
> kvm_create_guest_memfd. When set, KVM builds an MPOL_BIND policy for the
> requested node and installs it over the whole inode, so every folio is
> allocated there with no userspace mbind().
>
Instead of a custom API to ensure all guest_memfd allocations come from
a single node, how about these options?
1. Using cgroups/cpuset to constrain allocations (could be troublesome
if the guest memory is not preallocated, unless the vCPU threads are
running with the cpuset config)
2. Process-level NUMA policy
3. Why not request the guest_memfd to be mmap-able just to be able to
set a memory policy?
4. How about something like fbind() that takes an fd and offset range
instead of mbind(), which has a prerequisite on mmap()?
This doesn't exist yet, but I'm hoping to discuss this at LPC 2026:
5. What if you could pass an fd representing a mount to guest_memfd at
creation time, so to make all the allocations come from a single node
Step 1: Create a tmpfs mount, specify mpol for mount to MPOL_BIND
Step 2: Get some fd representing the tmpfs mount, hand that to
guest_memfd at creation time
Step 3: guest_memfd allocations will always come from that tmpfs
mount, and abide by that tmpfs mount's memory policy.
May I know more about the use case behind this new feature?
>
> [...snip...]
>
