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 CED3FC021B8 for ; Tue, 4 Mar 2025 15:30:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46C83280002; Tue, 4 Mar 2025 10:30:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 41CA26B0092; Tue, 4 Mar 2025 10:30:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E481280002; Tue, 4 Mar 2025 10:30:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0D9FE6B008C for ; Tue, 4 Mar 2025 10:30:25 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A0F4CA1641 for ; Tue, 4 Mar 2025 15:30:24 +0000 (UTC) X-FDA: 83184255168.20.7188B02 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) by imf04.hostedemail.com (Postfix) with ESMTP id 9F4F240014 for ; Tue, 4 Mar 2025 15:30:22 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZLww8lgh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of 3jRzHZwYKCCgWIERNGKSSKPI.GSQPMRYb-QQOZEGO.SVK@flex--seanjc.bounces.google.com designates 209.85.216.74 as permitted sender) smtp.mailfrom=3jRzHZwYKCCgWIERNGKSSKPI.GSQPMRYb-QQOZEGO.SVK@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741102222; a=rsa-sha256; cv=none; b=lTKQyf4g4sNDbJyBQmEk5A9R7Us7IVxY/ajWaTDgV9qBnGZxXfuLGpgUHxLWZM2brfFua0 AoZhHx0W5kmt6pJLgt9DLWAORLMG7MM9HO/Rtqk1DW4DkQD9Vd1r7V3WbCB3laq1vBD6e9 C1vkocV/0ff+2qFRpOwClpfAmEbtZuM= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZLww8lgh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of 3jRzHZwYKCCgWIERNGKSSKPI.GSQPMRYb-QQOZEGO.SVK@flex--seanjc.bounces.google.com designates 209.85.216.74 as permitted sender) smtp.mailfrom=3jRzHZwYKCCgWIERNGKSSKPI.GSQPMRYb-QQOZEGO.SVK@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741102222; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cvg9RGNtgXTSILk0IdpR94FQL1jxJC1gyLgPdqw8XU0=; b=PN0Z2IW5SatPIrCVxe/v3FIZV+khd25BlO+8g7HimJbjNj2EMwYxwNj6JhrBPB6cm4lO+d 0o5L4CsDiGJs8zG9uLpXnUCDIVmXeAwsy0kRtEVPd4InwaaMAWDfXT/OI5Hm0AD/4pooON 8PVX/JbfkUG9yNf2lPpSBf8Qgnn/TMI= Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fed20dd70cso6345591a91.1 for ; Tue, 04 Mar 2025 07:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1741102221; x=1741707021; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=cvg9RGNtgXTSILk0IdpR94FQL1jxJC1gyLgPdqw8XU0=; b=ZLww8lghRPvRuQGUZsycUHq8ECXc0+6dvbk16wSLi+19YBpF8/IArYiLXxbWyPheoN ulaLtXBUDQ4DsWKG9zPRVEFdToPY4GyiQPOApQEn2V6zB+hf1uv7PZJoT9DI04pO4jB7 Xq97w843lkki+7w0NKsv+iSAO1Q9hELQPZowMHimR5j1oeToHAdHEa1fFmTmcqIbmF2D pbHx1dtR01KyqkZ0op8uNOPRGqcqmsHnWkiFJ0BXkWcUH2wvkbSrRmfqDhVbMqrlgXZM rfqyCLReLizuGMQLsThMFYrRJso+7XB4KeZI63CxOQn9oWdkjl75JLHuqmm7KcUhtXqJ s1xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741102221; x=1741707021; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cvg9RGNtgXTSILk0IdpR94FQL1jxJC1gyLgPdqw8XU0=; b=KgG7Yn3azegSocuLfcGhP+sD/YYkBkOwSEWyxVGoDIELU9kbsjGPJ56DX26ss4I05G AkKX0kMJtpEGwbse0c4DErTnwaoWCOwJYQXQl5+zM3fKf4HyRIHL+ftKBho+jKi695WX Q1EiQZPUPn724Sb8VgssJ+kygchpY6NGonvAseXdkHVuVyQ1T/7iTR1jLqGQ3wYU/PPO 7AQSN/IbygkPDIg1mFOjmC8eJelaXqEOAA2LuQfvivwd1YL/90DJ0c2AvIer4LmTHNmh msmS8MZdEjTDHkkiK/wL3lIkpnXMZHL49fZ8ahH/E5WgRz/skLGxH/O20XZS50faBls6 cE0w== X-Forwarded-Encrypted: i=1; AJvYcCXu2z+4lDxLXfNj6QyvxIdqP5Aiwh4VybkTNF7bs7aYup8aD7eAu8DNi1RHVS93LmBI52qbgeRHNA==@kvack.org X-Gm-Message-State: AOJu0Yyo0RHt3327/DSGndQrAzokqEmo831gQX9tJx2DQF8y0hfULc/U dHCa2klrzBHCHQVUaDyo6BXMbSIVPWUPVFKY3L8SiQKUg0dfsIRu3yAnzZRhQ7a9CKeK4zTnoHy DdA== X-Google-Smtp-Source: AGHT+IEM4E5/Zptus46DoKrgzz5+XTeSJ4hJIAQWQAIYRnIL9pjg60K5aKaF81Eu644JbhsDlC5832QLpoQ= X-Received: from pjur6.prod.google.com ([2002:a17:90a:d406:b0:2fc:2959:b397]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2c90:b0:2ee:db8a:2a01 with SMTP id 98e67ed59e1d1-2febac10a9fmr26741760a91.30.1741102221273; Tue, 04 Mar 2025 07:30:21 -0800 (PST) Date: Tue, 4 Mar 2025 07:30:19 -0800 In-Reply-To: Mime-Version: 1.0 References: Message-ID: Subject: Re: [PATCH v6 4/5] KVM: guest_memfd: Enforce NUMA mempolicy using shared policy From: Sean Christopherson To: Ackerley Tng Cc: Vlastimil Babka , shivankg@amd.com, 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, 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 Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 9F4F240014 X-Stat-Signature: urwq5oy4d78frhckne931u374cdwe5sn X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1741102222-230955 X-HE-Meta: U2FsdGVkX1/wPsC+lGlKV10gnCqqCWTr0gZESK24jE6LbCQ1hjkW+UGMLXCLWqimXuIeVKLFND4qpxL9XKlGn9kYqgsD7zaoKQRbHtAFizPAY4hW5jHVyA71/dvI0PJtcyW5JcoD+SCfrajN97PzwCW0Lz1pCB3/qwnpfsLvl+yI5WlTriHTjQDWVyuq0lQgV++SEB7omIONUVAhwDG1jHLLb6hxdU+Nn0GSxCFfJitoTs/vITpVW960boiCwJr25y4PJwtfZWA9DPGtvGUYeK0Da8lgDLzCmNUyLmyhnr8ClHphOwXGdgesuL0E3vX5FsklY4AHGAA6zp2Tq5h5OH0bpGaowwW6aUMdQ2C+m4OpZVsZzBcgoqOqWe3I9fuSyj38uGMNtuDXZ6xWt0canJx6WAFm3r8V9bvRCCLOuqnDqbUfykMlfvg3liK6bdYG/p7tAQc/0bXyHXo5+oAj4dEXs/mXcJ8g9GcfvgYeWetDSYo5k0Saa98FeKOB62unMcgP3YQ1UoBPqexajMj6nSQhM2yUjgtaS/qjv/oG9QviPeruxY0+HzXKQjXzpGKHOln4zbO3hMug0E5paLAlfZdfrkh4g5amd1kKY4a8diuxkFbNTw9NMCvhrUnaM95PEz3iaju03dPbKRR98EIx2KMA7W9ZGOZkLRyJPbYqShBOlH0teXWZj//VsWChWMCSO92TdXm62uJ7ExuptG7F8p9SK5Tf1eDz0mxLKChVcVhutIAQYQCY6z4LJuuXztrKmOpuSTKZnJTT6qP7QSkM0a1vyFdGkiPdlK3FWCmBgwn5lw7rh133pV1V+uqF5w8OfBB6GuvgS4nm8kpmAaGET9n4IMAOjH6XGMnWc8ZbSjsYdVh8EVqfWxM3vZD+CgwzSCiYXlAuLzj74y1kRXgUK2LxRrLn1jDS9NITIBcMYj7pXayYrNr0om2l9d9UPKGAO1e5JucGocUupDuxE2P JDQGEo9N eBFUBKAIuBEiI899uKuweM3xYfTpJYiqmIBWNKhcoNCfhnKJ4Rqftp+KwkEfhm+8nZP2GLa5I0pK3jrI5RTZ6gQOOqyM1rewCxGbesbhrJ/M9+a9sph+h2+6VebArtlOHdeyUT0USHZZh7xhCVxidg/PqpcVsTMkZjfO9a8fWDANzkmvNGgUc+Td6r83BHY9hUGoKQqPFgrArmucV2X5oXU8rsfWhbK2A42h7cq4TcK21+7ktMU7m72NkcwdG+IhMMuu0bFqvVLVmN1gb2fwC6rTvRabEiY/KIYhnyqscuVRAgIinCJeNZ6lGM++pv3pSGPNtaz3FJheq9daKWrDD775kWiPbvQJciXJCF5Kj91l26iIijIVyr7Md4AqchcOWNNcA7+F7b4+/u5o1rI3yBIIFXOy+1yad/7tySG6VP731y6invxrLKq9arjBkMdkj4O6L5ORXlFMTqQPjCmQ5cQRKCIpvoA6NkUQibB4iw32aagJbVZEsZe9/K+87IAV1RYq2N4ToB1JqmYY6VdXBpDKfuQo1ePyYg+BaP57/Q8wzr/yRFMb5Hs0VkK29JIrTjVLe/OnQvLSfyfVeJtT3bI4RLy8ocgQDg+REkzc+MsuxdmuMvnuf56zeICVrP1HnTh1Yp4gXVE2s9YhMSsODMaP2oA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000083, 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 Tue, Mar 04, 2025, Ackerley Tng wrote: > Vlastimil Babka writes: > >> 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. > > Here's where Sean described file vs inode: "The inode is effectively the > raw underlying physical storage, while the file is the VM's view of that > storage." [1]. > > I guess you're right that for now there is little distinction between > file and inode and using file should be feasible, but I feel that this > dilutes the original intent. Hmm, and using the file would be actively problematic at some point. One could argue that NUMA policy is property of the VM accessing the memory, i.e. that two VMs mapping the same guest_memfd could want different policies. But in practice, that would allow for conflicting requirements, e.g. different policies in each VM for the same chunk of memory, and would likely lead to surprising behavior due to having to manually do mbind() for every VM/file view. > Something like [2] doesn't seem like too big of a change and could perhaps be > included earlier rather than later, since it will also contribute to support > for restricted mapping [3]. > > [1] https://lore.kernel.org/all/ZLGiEfJZTyl7M8mS@google.com/ > [2] https://lore.kernel.org/all/d1940d466fc69472c8b6dda95df2e0522b2d8744.1726009989.git.ackerleytng@google.com/ > [3] https://lore.kernel.org/all/20250117163001.2326672-1-tabba@google.com/T/