lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba19f253-e46f-4cb4-9681-fa1d0b43bc31@amd.com>
Date: Tue, 22 Jul 2025 21:19:31 +0530
From: Shivank Garg <shivankg@....com>
To: David Hildenbrand <david@...hat.com>, seanjc@...gle.com, vbabka@...e.cz,
 willy@...radead.org, akpm@...ux-foundation.org, shuah@...nel.org,
 pbonzini@...hat.com, brauner@...nel.org, viro@...iv.linux.org.uk
Cc: ackerleytng@...gle.com, paul@...l-moore.com, jmorris@...ei.org,
 serge@...lyn.com, pvorel@...e.cz, bfoster@...hat.com, tabba@...gle.com,
 vannapurve@...gle.com, chao.gao@...el.com, bharata@....com, nikunj@....com,
 michael.day@....com, shdhiman@....com, yan.y.zhao@...el.com,
 Neeraj.Upadhyay@....com, thomas.lendacky@....com, michael.roth@....com,
 aik@....com, jgg@...dia.com, kalyazin@...zon.com, peterx@...hat.com,
 jack@...e.cz, rppt@...nel.org, hch@...radead.org, cgzones@...glemail.com,
 ira.weiny@...el.com, rientjes@...gle.com, roypat@...zon.co.uk,
 ziy@...dia.com, matthew.brost@...el.com, joshua.hahnjy@...il.com,
 rakie.kim@...com, byungchul@...com, gourry@...rry.net,
 kent.overstreet@...ux.dev, ying.huang@...ux.alibaba.com, apopple@...dia.com,
 chao.p.peng@...el.com, amit@...radead.org, ddutile@...hat.com,
 dan.j.williams@...el.com, ashish.kalra@....com, gshan@...hat.com,
 jgowans@...zon.com, pankaj.gupta@....com, papaluri@....com,
 yuzhao@...gle.com, suzuki.poulose@....com, quic_eberman@...cinc.com,
 aneeshkumar.kizhakeveetil@....com, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 linux-security-module@...r.kernel.org, kvm@...r.kernel.org,
 linux-kselftest@...r.kernel.org, linux-coco@...ts.linux.dev
Subject: Re: [PATCH V9 0/7] Add NUMA mempolicy support for KVM guest-memfd



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@....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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ