From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7AFB5C282C5 for ; Mon, 3 Mar 2025 08:58:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B408280021; Mon, 3 Mar 2025 03:58:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 03B23280005; Mon, 3 Mar 2025 03:58:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCFEA280021; Mon, 3 Mar 2025 03:58:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B98EF280005 for ; Mon, 3 Mar 2025 03:58:56 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7FA82C04D6 for ; Mon, 3 Mar 2025 08:58:56 +0000 (UTC) X-FDA: 83179639872.11.24A809D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf10.hostedemail.com (Postfix) with ESMTP id 1AC8EC0006 for ; Mon, 3 Mar 2025 08:58:53 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=B8CnYRgD; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=8rEpUTS9; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=B8CnYRgD; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=8rEpUTS9; dmarc=none; spf=pass (imf10.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740992334; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aSON7+XnjGfp+c6nCY9Q1Nyp8iCGTByScIrdxR+QXcU=; b=YZPCEH4eCmNJpPT0JZQxwKQjwGRaNyEovvjBAJA3HqC9NyBqZb2CWt6VSwUq2LnOklkhxA 7EfN9kVmoKl8tVd0fF5bDunRPRIiFu8kk5m8vBpDuVxk2vM4IB/snVzOFl/4JNbVsIZgxL Y5Azc4/z1+WLejFROR9qolyKSJfUmcg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740992334; a=rsa-sha256; cv=none; b=0/oVyYQwLh10BUPuIphSkvfYO5FiNwXMDBsa8teQQoWv8v8uNlnkwrwTHeWNTO8tpQEjua E9Ap4FO5+wJjYhOD9dpbz0PWto9sCyFJZYz1uXg1M77bZeTvIss5Bhtux6i6ppqKIBcE+e M+qeYS8z/xdCMeHWSzshNENLIYUAk4M= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=B8CnYRgD; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=8rEpUTS9; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=B8CnYRgD; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=8rEpUTS9; dmarc=none; spf=pass (imf10.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 40A462117A; Mon, 3 Mar 2025 08:58:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740992332; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=aSON7+XnjGfp+c6nCY9Q1Nyp8iCGTByScIrdxR+QXcU=; b=B8CnYRgDFesPnktfWJW3OZH+DNLlQUg2CuQ00iXZpbMajpG2B6/garfUkEbOFCfiflnKmQ A3+srEERN74fzyDoxhcoWqgestuE1o9MPwGpaUA+CQtjoZilWaHrPLVQtl3WrfoZfNM9yS nlDlPu7MeKKtkb9AmeiuqNB69h8Uj7E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740992332; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=aSON7+XnjGfp+c6nCY9Q1Nyp8iCGTByScIrdxR+QXcU=; b=8rEpUTS9caaL2Wrykctdl/I1wdPdVYVyRksK83SPToX2ti1iYIu9q/ccAw793D7E9potHg vbRbExkz2osvc3CQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740992332; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=aSON7+XnjGfp+c6nCY9Q1Nyp8iCGTByScIrdxR+QXcU=; b=B8CnYRgDFesPnktfWJW3OZH+DNLlQUg2CuQ00iXZpbMajpG2B6/garfUkEbOFCfiflnKmQ A3+srEERN74fzyDoxhcoWqgestuE1o9MPwGpaUA+CQtjoZilWaHrPLVQtl3WrfoZfNM9yS nlDlPu7MeKKtkb9AmeiuqNB69h8Uj7E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740992332; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=aSON7+XnjGfp+c6nCY9Q1Nyp8iCGTByScIrdxR+QXcU=; b=8rEpUTS9caaL2Wrykctdl/I1wdPdVYVyRksK83SPToX2ti1iYIu9q/ccAw793D7E9potHg vbRbExkz2osvc3CQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 0B97913939; Mon, 3 Mar 2025 08:58:52 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id nQCHAkxvxWdXeAAAD6G6ig (envelope-from ); Mon, 03 Mar 2025 08:58:52 +0000 Message-ID: Date: Mon, 3 Mar 2025 09:58:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 4/5] KVM: guest_memfd: Enforce NUMA mempolicy using shared policy To: Ackerley Tng , Shivank Garg Cc: akpm@linux-foundation.org, willy@infradead.org, pbonzini@redhat.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, chao.gao@intel.com, seanjc@google.com, david@redhat.com, bharata@amd.com, nikunj@amd.com, michael.day@amd.com, Neeraj.Upadhyay@amd.com, thomas.lendacky@amd.com, michael.roth@amd.com, tabba@google.com References: Content-Language: en-US From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1AC8EC0006 X-Stat-Signature: 5ifqfcyh3rsw7qxaxcpxcno7bwcg5m9x X-HE-Tag: 1740992333-433396 X-HE-Meta: U2FsdGVkX1/mknVlUta9Y00xAJ0FnHeIXFORjv/aAs6MyUJ97ZO4WkzxyacvjawDBieIhQ4zKTRiqQIgRhVD50E3u8r70RgHY/bdhj0l7QDtkBJ3+c7YlfdrrD/qyfoga87dLTIYvKx7ueX0xnWF3FwRwiHC8RPYdsDf8XEZWkhsGY+/0Ldm/g3/8p89ILm5oUpBnMR9V3EsF5YNoKxk8chJatzYUQxmxIdtIzL2UHmrBN7i4A5wCuGjF6aY/ze/+CA8sMNnEnlj0gtdzd4YicukrZaP4YBbykS1sg5ILXoTiGlIzCZYwcrgqEl3Wb1cPnc+GJ9ZzTiiuwwekhS7bJHPwG6Wv9UBMt7zxLtH7EiN+Rft1gcfcQhRTLbqRR3M1XbMDWVdDehStLSB5zlMenv/ei7WEUUrbmuxrx2lD3OJLrLWTqHyXCxjz4a64rnXKiEc5ozcK4oDNfli9h6XlmlFl5owPoaybXpnGr8HrR73QfNN95u+YmOJIiwoWmOdNSVP2z+8xMLVzbxlYDFkQXGCq3syBhQ5rzqOIk/OXzvTmKz8u7ltmvi0ntif/S/WporMAJnlKlvIIcwSl6ORszHoBDkmvbMdbB/wMytWp46Cy1uONXDNE+/vSSjHEJYsK60PJ8GBKLsSHFz3xHxrnPf6/IFcl7fhbjYa2gt1jVRtaQWJnERX8+bqnZz2ornPrh2OrFnSwrkvXaUhirbXfnxJLEAwLL6Qu/so3Bg9Gtz1Va63KsH/780Kr/9nodcSmeKd5LQTpFMHcsSQrtbGexHw8enALopMe4HyQcSbx+hVxhuHSs40qfqHXT38XRt6YUY59pTbRbutIrCYL2hHTBcrsjtvls2cf+bvoLEMjjsHT6PuAh0I1iRImUfm6IinydI/255V9LmiqWSEmyA1CMtqc3ySS1GaxXyK74Synn74cuQN9PJPxqS7iRaFrz3TaqTp3T+8RmBaLJKydOT W0A+pB1o 7Pefu9yPDUzpi0ZSNXunn39ochdzAmoCAIp794CGZwk0sksWyBGx9pOh8JwXPtEjleDGzn8ron1B3n4zvdwN0CnHPHEhkwRUUvN/YY3ihkamVRMAO1JN2yU0B0wTsdVbvf6c9FPf0Fm+X3RHfoTpGGfDkgb+uktWWAeSFrxAdz+BGRm0o6zgruDLFZf7T8/Eiz/XSnyzNiJYiFBt5rdeN3MSmAKEiRmB+anEj8it3GkF77iFq2srkGU/njxb4iCM9v5OZd1ytgZzMP9LegGikYyZT+auovrIm62ttpAUMEcBS5EGkAsJSJFQiLFygoasjIl7ik8SJF8yGvIZdARg8EJLip6umQ470FL/lTeC8JULBHJZwyzQFtEafT7Tz7XqgzScJ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2/28/25 18:25, Ackerley Tng wrote: > Shivank Garg writes: > >> Previously, guest-memfd allocations followed local NUMA node id in absence >> of process mempolicy, resulting in arbitrary memory allocation. >> Moreover, mbind() couldn't be used since memory wasn't mapped to userspace >> in the VMM. >> >> Enable NUMA policy support by implementing vm_ops for guest-memfd mmap >> operation. This allows the VMM to map the memory and use mbind() to set >> the desired NUMA policy. The policy is then retrieved via >> mpol_shared_policy_lookup() and passed to filemap_grab_folio_mpol() to >> ensure that allocations follow the specified memory policy. >> >> This enables the VMM to control guest memory NUMA placement by calling >> mbind() on the mapped memory regions, providing fine-grained control over >> guest memory allocation across NUMA nodes. >> >> The policy change only affect future allocations and does 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, which are not supported for guest_memfd as it is unmovable. >> >> Suggested-by: David Hildenbrand >> Signed-off-by: Shivank Garg >> --- >> virt/kvm/guest_memfd.c | 76 +++++++++++++++++++++++++++++++++++++++++- >> 1 file changed, 75 insertions(+), 1 deletion(-) >> >> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c >> index f18176976ae3..b3a8819117a0 100644 >> --- a/virt/kvm/guest_memfd.c >> +++ b/virt/kvm/guest_memfd.c >> @@ -2,6 +2,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> >> @@ -11,8 +12,12 @@ struct kvm_gmem { >> struct kvm *kvm; >> struct xarray bindings; >> struct list_head entry; >> + struct shared_policy policy; >> }; >> > > struct shared_policy should be stored on the inode rather than the file, > since the memory policy is a property of the memory (struct inode), > rather than a property of how the memory is used for a given VM (struct > file). That makes sense. AFAICS shmem also uses inodes to store policy. > When the shared_policy is stored on the inode, intra-host migration [1] > will work correctly, since the while the inode will be transferred from > one VM (struct kvm) to another, the file (a VM's view/bindings of the > memory) will be recreated for the new VM. > > I'm thinking of having a patch like this [2] to introduce inodes. shmem has it easier by already having inodes > With this, we shouldn't need to pass file pointers instead of inode > pointers. Any downsides, besides more work needed? Or is it feasible to do it using files now and convert to inodes later? Feels like something that must have been discussed already, but I don't recall specifics.