On 9/10/26 01:10, Gregory Price wrote: > On Wed, Sep 09, 2026 at 03:41:35PM -0700, Ackerley Tng wrote: >> 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 >> > > for 1 and 2: > > the intent is to put the guest memory on the target node, not all system > memory for a given process. so the scope here is not the same. > > in fact at that granularity, the desired node may not even have eligible > memory to host the task's memory. > >> 3. Why not request the guest_memfd to be mmap-able just to be able to >> set a memory policy? >> > > the eventual intent is to enable this for fully confidential, > host-unmapped guest, isolated to a particular memory device. > > Requiring a mapping to get node-placement is quite defeating the point.
You only need a VMA, not actually mapped/faulted pages. So I don't immediately see the problem? -- Cheers, David
