Re: [PATCH 0/5] KVM: guest_memfd: bind backing memory to a NUMA node

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/10/26 01:10, Gregory Price wrote:
> On Wed, Sep 09, 2026 at 03:41:35PM -0700, Ackerley Tng wrote:
>> Gregory Price <gourry@gourry.net> 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