Re: [PATCH V9 0/7] Add NUMA mempolicy support for KVM guest-memfd

[Shivank Garg <shivankg@amd.com>]

On 7/22/2025 8:10 PM, David Hildenbrand wrote:
> On 13.07.25 19:43, Shivank Garg wrote:
>> This series introduces NUMA-aware memory placement support for KVM guests
>> with guest_memfd memory backends. It builds upon Fuad Tabba's work that
>> enabled host-mapping for guest_memfd memory [1].
>>
>> == Background ==
>> KVM's guest-memfd memory backend currently lacks support for NUMA policy
>> enforcement, causing guest memory allocations to be distributed across host
>> nodes  according to kernel's default behavior, irrespective of any policy
>> specified by the VMM. This limitation arises because conventional userspace
>> NUMA control mechanisms like mbind(2) don't work since the memory isn't
>> directly mapped to userspace when allocations occur.
>> Fuad's work [1] provides the necessary mmap capability, and this series
>> leverages it to enable mbind(2).
>>
>> == Implementation ==
>>
>> This series implements proper NUMA policy support for guest-memfd by:
>>
>> 1. Adding mempolicy-aware allocation APIs to the filemap layer.
>> 2. Introducing custom inodes (via a dedicated slab-allocated inode cache,
>>     kvm_gmem_inode_info) to store NUMA policy and metadata for guest memory.
>> 3. Implementing get/set_policy vm_ops in guest_memfd to support NUMA
>>     policy.
>>
>> With these changes, VMMs can now control guest memory placement by mapping
>> guest_memfd file descriptor and using mbind(2) to specify:
>> - Policy modes: default, bind, interleave, or preferred
>> - Host NUMA nodes: List of target nodes for memory allocation
>>
>> These Policies affect only future allocations and do not migrate existing
>> memory. This matches mbind(2)'s default behavior which affects only new
>> allocations unless overridden with MPOL_MF_MOVE/MPOL_MF_MOVE_ALL flags (Not
>> supported for guest_memfd as it is unmovable by design).
>>
>> == Upstream Plan ==
>> Phased approach as per David's guest_memfd extension overview [2] and
>> community calls [3]:
>>
>> Phase 1 (this series):
>> 1. Focuses on shared guest_memfd support (non-CoCo VMs).
>> 2. Builds on Fuad's host-mapping work.
> 
> Just to clarify: this is based on Fuad's stage 1 and should probably still be
> tagged "RFC" until stage-1 is finally upstream.
> 

Sure.

> (I was hoping stage-1 would go upstream in 6.17, but I am not sure yet if that is
> still feasible looking at the never-ending review)
> 
> I'm surprised to see that
> 
> commit cbe4134ea4bc493239786220bd69cb8a13493190
> Author: Shivank Garg <shivankg@amd.com>
> Date:   Fri Jun 20 07:03:30 2025 +0000
> 
>     fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass
>     was merged with the kvm export
> 
>     EXPORT_SYMBOL_GPL_FOR_MODULES(anon_inode_make_secure_inode, "kvm");
> 
> I thought I commented that this is something to done separately and not really
> "fix" material.
> 
> Anyhow, good for this series, no need to touch that.
> 

Yeah, V2 got merged instead of V3.
https://lore.kernel.org/all/1ab3381b-1620-485d-8e1b-fff2c48d45c3@amd.com
but backporting did not give issues either.

Thank you for the reviews :)

Best Regards,
Shivank