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 53AFBC282D2 for ; Tue, 4 Mar 2025 16:59:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB0266B0082; Tue, 4 Mar 2025 11:59:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D5F876B0085; Tue, 4 Mar 2025 11:59:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C26B26B0089; Tue, 4 Mar 2025 11:59:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A46086B0082 for ; Tue, 4 Mar 2025 11:59:25 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 378534E681 for ; Tue, 4 Mar 2025 16:59:25 +0000 (UTC) X-FDA: 83184479490.12.AE31FF6 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) by imf17.hostedemail.com (Postfix) with ESMTP id 5F3CB40009 for ; Tue, 4 Mar 2025 16:59:23 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kATzlY76; spf=pass (imf17.hostedemail.com: domain of 3ajHHZwYKCC8dPLYUNRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3ajHHZwYKCC8dPLYUNRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741107563; 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=V7W7yQmf61Pq53pMS2vzrgU7eZq7ZkAtUnxQ4fLwZP8=; b=wc+JTPZHDifJI1XGHO939gHGsOGBZFhWLbtMuqpALJR64SjA+q6CpcWUwfnkQw5GYlGGBm zVh2IN9Idffc9YQ6ee15aNcsZd+nkhYCz66sa8xsJAtSZK6GS4+N0hCh9Y+n9PkYswgaEm xone02aCsQ+1l0erXw8R8CBeCDMZ2Bc= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kATzlY76; spf=pass (imf17.hostedemail.com: domain of 3ajHHZwYKCC8dPLYUNRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3ajHHZwYKCC8dPLYUNRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741107563; a=rsa-sha256; cv=none; b=ovMh7djRnwda+qMppzU7DlY/IUId2RVEH/rf+v/vL1JZPzTAfS54bQBt188e9RTqK0fmQj uK0gDXyBgX2TaKLQrD2WjCHRjXtWNMDfTC32We9KYFa4SZvv/tsVeLIKWPQ0CeKXJFPIxF MhR0AQl+R+I4DP+DfdRRVdkmUzMOqE8= Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-22387acb40eso97043995ad.3 for ; Tue, 04 Mar 2025 08:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1741107562; x=1741712362; 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=V7W7yQmf61Pq53pMS2vzrgU7eZq7ZkAtUnxQ4fLwZP8=; b=kATzlY764uqV6dpk3fDGSh1ipi8R74X9ZfSNUBNI58bKZqqUniI9PZbsxvmrh3xVfG tu24VQsD8w7sSRxzO9jfT9bkxIlYRBLl4YcCiB/29kWPxrx2Fd0c/FOqUCA/P528bRlM xdgJ8/1j0fWN1+8ZLXiuBKnb8W8oq35LWCPauNqLsT6zgshktuSvNLqFi5aw1C7G6bHo vSKa1IKrqzVcy3UdcF/zr9LQK0W+Ba1ZdwEvEIs9O2wekL7mU7oeS6kzFSPJM2DFnWZg jn/8g42LWvMe+bIydH4YHsXQGoUqjBZyzfNHk7egLkSE9U/fnzoCTgp7vqNckOTMPT2R xMZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741107562; x=1741712362; 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=V7W7yQmf61Pq53pMS2vzrgU7eZq7ZkAtUnxQ4fLwZP8=; b=LtAZ6mBotmryT6hFf7HIeZktVrtR7Nt7bkt8oOnRnYvTXzdwLG07h12eIYhrY7Kr9c zGgP7veX5VjXTQ4Zi6ma4TKkSHQvTN3zpawu1ZCtTs/i/uDH+NBqtn1b97pfMKAbM/JJ jeyjU4WUE1uDdLJnUPDwp5ODfFJhssBRSmodPiJgZO67eoyJbdHWVaXZE3lW5y5+yxO9 xfVfZUy2p5UuoKv+kdVwo/aCSCTSRv/WFp0xIiAGeJns3WyoxjEn68oRtcurMUbmczjt KHB/a18dv81zNaypnEGPDfFcp7nwhVyqSFkE7ykhZU2w3S6Qzti6agbjC7Qd0PDi/3oy TMPg== X-Forwarded-Encrypted: i=1; AJvYcCXtY/PoV0rTAQ1h72pIYsbrmi/4I5OKyjmQ8tKp4Xl2Eyjr779TXAywEOfiM/RZ0cw+blPDFEsDeg==@kvack.org X-Gm-Message-State: AOJu0YyH32Dviuavd9A3ozK3rCt7P6DEhzxJRSnUEImkBllDUIvUZLLb T8Bn2wgxO3r9w/M1NbnreS5pCYsoPATalO0wSntRq+yOjN9tlp87N/vzuSl9e5izP4Y4PZlm0bL VFw== X-Google-Smtp-Source: AGHT+IHAFrEgPQdnRru2RpcA9ojFQVDAwMfLY/u9ofYMqa8EKlltfiiKVsKJDm4SpBm3Hx0wphR2ehXHeKw= X-Received: from plbju14.prod.google.com ([2002:a17:903:428e:b0:220:e84e:350c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:3b83:b0:221:7955:64c3 with SMTP id d9443c01a7336-22368f9d123mr262199705ad.23.1741107562128; Tue, 04 Mar 2025 08:59:22 -0800 (PST) Date: Tue, 4 Mar 2025 08:59:20 -0800 In-Reply-To: <9d04c204-cb9a-4109-977b-3d39b992c521@redhat.com> Mime-Version: 1.0 References: <9d04c204-cb9a-4109-977b-3d39b992c521@redhat.com> Message-ID: Subject: Re: [PATCH v6 4/5] KVM: guest_memfd: Enforce NUMA mempolicy using shared policy From: Sean Christopherson To: David Hildenbrand Cc: Ackerley Tng , 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, 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-Stat-Signature: b7g51u5zz9ieftgckhmremo9h7ym7fr6 X-Rspamd-Queue-Id: 5F3CB40009 X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1741107563-520830 X-HE-Meta: U2FsdGVkX18b2lrgI1uKviChMS4Xpr2aXBgYDMg5Kq1OhAsQW8jTcDpQMMZrbQxSrfBO/1d/UaGXJ1QFQhyCtaqYwfEvBrMFb6beP3fqnlu9oZYpnG6PO7jYGnmhKJZWu96SAEGF/9HT7jJEPaqWsyndN2KFTO3d2EWNczY0+/SmDjPGMEmqBJa1A8h3VUQ5d2/jtNxRtDK8eBJdUWzLZ37X58u5RGdhT2DkyU98zyRP8uY94pnWEy04SE+qRDJl9XNP8moEX5usconzUdpaQgglZFaMyp46fVdpgtpcW7YtjMfKKat7YxJC1nEUBrduAL7KLZkERDwmIzXvk+/ad6RQpHZk40Jiz/o0V5b+/VVrd37bx4yEq3VBfpVCeoma/7wxrenqvlLnPajmY1YyJMC5NKw0HGgtRZnq35xbVjbHmgHl/stB9Qjgqeye5AWPc4ojSVBo12FkmW2jgZ0rX6hF82BlDcM25bsXIdR9YcIQhwvz69fSm4iTIN8X2GZK9Zi7tw1I2Fc1o0UX2Xg4cwHRwJ131OBwOwEvQ0Kcoqyqfrz6RcgV5Vi9e7/F/48wG4rph0igr4Uf+RlzT+aWkizFOTQVdyoT0Mphjvbsaj7ZZATqOnwZxAXgODcDxtFylzXH5c+duB1VcfkjrLREOebmtNUfN4K/lLmyjyVA2qasd9LwaHhAVuuz2YOPADeqt3tibu7UKuqkP1nUW948YpiU3/lYZQAW3dIfCkiG3Re4ifXaJd8j41/Z4A20k1bch2lcLbLjmgu5/Jq91owFcuzEil7at4nPGvBX+ZxZh7MRcB29oMB57NN1nFyij7aAYR7j9IqezWbmEiK6tOSKYUCYI7paZQYI7Oobk9Hm1yzQ8rvROvQmDEMNHKInTHArtBgdh/LY+vvwwTHt/tHmskfP+DczukBx5KUdtnfZjMpKooQ+SXQGIkDIoMv/xr5UNRQXt7+5Vckwi6g79Fa jajzQpYn bY/+HHxASRgeA3WlabIl8R4HbonV/9y6zoAJRU3DFq0Nlis0xFfdesyTasaRT5rSL1Lw3N+Z1IpNtpqN+YOYVkXzCyTDI4Pm7R76aXrRHPccicRFJEQ9w6wLa4mS+PHlrbzyE7tL2rV5l0s3slSTkGlfVZvxtcMWb1QpGLA4uVC2w5aMq6vo+KSZuz1SeMTi8VHJPdSbQzy17PRqb0n9zscK6XALdPM+hqiK7sNVEe6nCVa7+VGHIb5zl9CRs84k1L8bR59M6ANLZ+Tm44Ak+U49JA4NoIERmTlVvVrmfMhzRMlvU2gXicomn+m2h28bAplMdfV9N+xWKkmV73DJS4ytdeWX6EZhz0xBmLdk3TWBh1i6aAq/0oJJWDieG+7W8LCyyquCyCmDy4BdUUGMbIqSbsx3cNSGmoOAEf5sT+rnHSZIX+Bt72e6gd22wNYZmv1NeVC7yuBnfrdI1RC0wbe/SpiNK/gWMRoHwgrsvjDCVZZGKbZVELWvCkQXF7wcx1UMHu+0D6dKxa4Guq5dxANQxwEdHeSASW0NrQD57/Bofesk2RtwhYqdeQE4OLmV85k/d24GG11ajgBMfd5SxQxIT1o1HQdjXUHfizWnO93ERrzm5+XnMGDemrxWRQfVoJ9874t5WtHftqFc= 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 Tue, Mar 04, 2025, David Hildenbrand wrote: > On 04.03.25 16:30, Sean Christopherson wrote: > > 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. > > I think that's the same behavior with shmem? I mean, if you have two people > asking for different things for the same MAP_SHARE file range, surprises are > unavoidable. Yeah, I was specifically thinking of the case where a secondary mapping doesn't do mbind() at all, e.g. could end up effectively polluting guest_memfd with "bad" allocations.