From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 49FFA299924 for ; Thu, 25 Sep 2025 14:17:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758809825; cv=none; b=eLIPf83Fp5cAyX73ChqK+9rI/Lv95BGFoYPY8z00oxQG5gYBZvC5NrWaQdLwmaXjOA4k/nCprxJVfmDSlTz8jP3daBygKtgjQR2fKRbt7Vj2+i721nsiPB42KhTCwMNT7O0t4NCwarCvhmbnnmJNnP/mbu0f9TtEtrA5TJ0gpi4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758809825; c=relaxed/simple; bh=mqqPbcRc1y90cS3KVveWh9IwNrxKa0lpS3/3p6HfGes=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=LaEXayC2zjsrr7qJF7SiV54nESW/wrZEG4HtkBfg5nw0amiO4BwsTkN4YKyJaL4yaVh86gO8klsQyvo4riiTNKzH5Jz59z+tzVOsNSUokTPoBTD1pKl38xxJHCYmzBwoAMFECUM2GeDJWYnNLpPRK+2HM8w1ClGbRZJLSRw4heY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=hb6PW2PH; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="hb6PW2PH" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-32e09eaf85dso1405136a91.1 for ; Thu, 25 Sep 2025 07:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1758809823; x=1759414623; darn=vger.kernel.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=q01z2q70uBCSgJYAVR+vis46yH2U6fCb9IpR1jV5kvA=; b=hb6PW2PHlQxtB7d2jjGi4OHqvoM4S3md5HqnyoZwcg9H+HTGxwPDJ5fNl2HwRjFa9L VxDAfuIfktCZ7eOKwml/pL7ix6pL5UclEt2N/cVylrmzKhQDPjW/D4DpFJ181jd1ktml YcR1TM2paVRAT68HIuZufQqb/PkBBKrR3Qq5ydMVF+7JtqfUg6gyyW033x4LV55KGqyS Tj3Q32nGPFQbSN/vxTF5TNeOuls+Z+iQA7Hb5+DtdzJnPRqiGVUXHBhlFhrl17g6TUHm qzQ837SD/InOQEEYjshLSnWqkUbJN0+xNtb3PSJjoL98N4q3+kgTN43PAvmYY16GuWvu 45Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758809823; x=1759414623; 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=q01z2q70uBCSgJYAVR+vis46yH2U6fCb9IpR1jV5kvA=; b=jlC4MaDh5xst/fTVBgAuf1wgWedYpUmZuFDK8tHIXwXlYYwHFn4WiAMfYgImXtrZNS C42GN9epuZWCio17P919azzbhn/zA75p9p/lM6HepXhcMCRPMgWltCV/kh+/e1zxy2gR 9XWCuTCZ2Du8mYOeF7GeEEccpmEz36JqAIVQNMYLZyTCIBH2x76TFz86Se8VmhkctS8p z8UkZGkfEaWPBPK3ZZsXKzjEdjTw5+n3zEkKedOtmjwl4W+uB0aho/Btcd8mi/hbeaTN 2vP4T/oGomLhPJzfNlWlhfrAfHMdIO+biejT878WPjiI9TxH/YNahCvgOEaQHySZ9WGm H0Tw== X-Forwarded-Encrypted: i=1; AJvYcCXLy+g32kbqBd7q5mBmA+IQkqxON8q1SOHN9LKqf1WIJnoLuGDFGCN62/yowIz3dlfEjAU=@vger.kernel.org X-Gm-Message-State: AOJu0YyNit4VCsWhevy+6DqUKJ3YGQSvW/I380JidqBAUpbTLJXm/Pgy l+C+PWQtXRf17YqYnZ6n1VGSjF8A3zPUH0JLuF5JDhepFYrcIRk++aC9VfI1Pku7LBERtyUy/oJ e53E67Q== X-Google-Smtp-Source: AGHT+IGC7UvA+zy0Lzxdig1u574Z6HM9V6jNvtPYVpQ99Zo3hDJZ7LLoK6uH5QRKE/XipBEFnMeanJ3T9fg= X-Received: from pjbon17.prod.google.com ([2002:a17:90b:1d11:b0:32e:e06a:4668]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3143:b0:32e:1ff5:5af4 with SMTP id 98e67ed59e1d1-3342a2fe9ddmr3876418a91.35.1758809822200; Thu, 25 Sep 2025 07:17:02 -0700 (PDT) Date: Thu, 25 Sep 2025 07:17:00 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250827175247.83322-2-shivankg@amd.com> <20250827175247.83322-8-shivankg@amd.com> Message-ID: Subject: Re: [PATCH kvm-next V11 5/7] KVM: guest_memfd: Add slab-allocated inode cache From: Sean Christopherson To: Shivank Garg Cc: willy@infradead.org, akpm@linux-foundation.org, david@redhat.com, pbonzini@redhat.com, shuah@kernel.org, vbabka@suse.cz, brauner@kernel.org, viro@zeniv.linux.org.uk, dsterba@suse.com, xiang@kernel.org, chao@kernel.org, jaegeuk@kernel.org, clm@fb.com, josef@toxicpanda.com, kent.overstreet@linux.dev, zbestahu@gmail.com, jefflexu@linux.alibaba.com, dhavale@google.com, lihongbo22@huawei.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, rppt@kernel.org, surenb@google.com, mhocko@suse.com, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, tabba@google.com, ackerleytng@google.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, pvorel@suse.cz, bfoster@redhat.com, vannapurve@google.com, chao.gao@intel.com, bharata@amd.com, nikunj@amd.com, michael.day@amd.com, shdhiman@amd.com, yan.y.zhao@intel.com, Neeraj.Upadhyay@amd.com, thomas.lendacky@amd.com, michael.roth@amd.com, aik@amd.com, jgg@nvidia.com, kalyazin@amazon.com, peterx@redhat.com, jack@suse.cz, hch@infradead.org, cgzones@googlemail.com, ira.weiny@intel.com, rientjes@google.com, roypat@amazon.co.uk, chao.p.peng@intel.com, amit@infradead.org, ddutile@redhat.com, dan.j.williams@intel.com, ashish.kalra@amd.com, gshan@redhat.com, jgowans@amazon.com, pankaj.gupta@amd.com, papaluri@amd.com, yuzhao@google.com, suzuki.poulose@arm.com, quic_eberman@quicinc.com, linux-bcachefs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-coco@lists.linux.dev Content-Type: text/plain; charset="us-ascii" On Thu, Sep 25, 2025, Sean Christopherson wrote: > On Wed, Aug 27, 2025, Shivank Garg wrote: > > Add dedicated inode structure (kvm_gmem_inode_info) and slab-allocated > > inode cache for guest memory backing, similar to how shmem handles inodes. > > > > This adds the necessary allocation/destruction functions and prepares > > for upcoming guest_memfd NUMA policy support changes. > > > > Signed-off-by: Shivank Garg > > --- > > virt/kvm/guest_memfd.c | 70 ++++++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 68 insertions(+), 2 deletions(-) > > > > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > > index 6c66a0974055..356947d36a47 100644 > > --- a/virt/kvm/guest_memfd.c > > +++ b/virt/kvm/guest_memfd.c > > @@ -17,6 +17,15 @@ struct kvm_gmem { > > struct list_head entry; > > }; > > > > +struct kvm_gmem_inode_info { > > What about naming this simply gmem_inode? Heh, after looking through other filesystems, they're fairly even on appending _info or not. My vote is definitely for gmem_inode. Before we accumulate more inode usage, e.g. for in-place conversion (which is actually why I started looking at this code), I think we should also settle on naming for gmem_file and gmem_inode variables. As below, "struct kvm_gmem *gmem" gets quite confusing once inodes are in the picture, especially since that structure isn't _the_ gmem instance, rather it's a VM's view of that gmem instance. And on the other side, "info" for the inode is a bit imprecise, e.g. doesn't immediately make me think of inodes. A few ideas: (a) struct gmem_inode *gmem; struct gmem_file *f; (b) struct gmem_inode *gi; struct gmem_file *f; (c) struct gmem_inode *gi; struct gmem_file *gf; (d) struct gmem_inode *gmem_i; struct gmem_file *gmem_f; I think my would be for (a) or (b). Option (c) seems like it would be hard to visually differentiate between "gi" and "gf", and gmem_{i,f} are a bit verbose IMO. > > + struct inode vfs_inode; > > +}; > > + > > +static inline struct kvm_gmem_inode_info *KVM_GMEM_I(struct inode *inode) > > And then GMEM_I()? > > And then (in a later follow-up if we target this for 6.18, or as a prep patch if > we push this out to 6.19), rename kvm_gmem to gmem_file? > > That would make guest_memfd look a bit more like other filesystems, and I don't > see a need to preface the local structures and helpers with "kvm_", e.g. GMEM_I() > is analogous to x86's to_vmx() and to_svm(). > > As for renaming kvm_gmem => gmem_file, I wandered back into this code via Ackerley's > in-place conversion series, and it took me a good long while to remember the roles > of files vs. inodes in gmem. That's probably a sign that the code needs clarification > given that I wrote the original code. :-) > > Leveraging an old discussion[*], my thought is to get to this: > > /* > * A guest_memfd instance can be associated multiple VMs, each with its own > * "view" of the underlying physical memory. > * > * The gmem's inode is effectively the raw underlying physical storage, and is > * used to track properties of the physical memory, while each gmem file is > * effectively a single VM's view of that storage, and is used to track assets > * specific to its associated VM, e.g. memslots=>gmem bindings. > */ > struct gmem_file { > struct kvm *kvm; > struct xarray bindings; > struct list_head entry; > }; > > struct gmem_inode { > struct shared_policy policy; > struct inode vfs_inode; > }; > > [*] https://lore.kernel.org/all/ZLGiEfJZTyl7M8mS@google.com 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4DD7ECAC5A7 for ; Thu, 25 Sep 2025 14:17:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:To:Message-ID:References:Mime-Version: In-Reply-To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VaejYIt1KadaQfXPFJAX6I6PhQKhIfxOGSCbMgmwVr0=; b=QmIjtkJpk4Z7c0Wyi7QqbK7VTV cLdhYGXxEuPyNuh2TuEAnKclCXCzaNGKN9p381+AKU+by6TUilH32l/fBEzU4wdSauZD4axPPC7WB 7jnRrLGHhrA2muoXKJ263+5l272UMqy/d1r4LIIMHPRoaZvuTV4SfVMoS7B8kITUXqV8=; Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1v1mmT-0005cp-K2; Thu, 25 Sep 2025 14:17:09 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <33k7VaAYKAB8N95IE7BJJBG9.7JH@flex--seanjc.bounces.google.com>) id 1v1mmS-0005cg-QQ for linux-f2fs-devel@lists.sourceforge.net; Thu, 25 Sep 2025 14:17:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=q01z2q70uBCSgJYAVR+vis46yH2U6fCb9IpR1jV5kvA=; b=MtpPkYoPl3Ey6FNxe9stb7lZSy EuLncuul3XZ2hdGUTo9EUsKIY7Va7W31MJVIpA7yENnV3XcHMdYvt/H+jPqwOEubaKEP4FKzx2mnK Kx4EdbhuymO9L8Alxva1bprhEnH+t103SiJbiS3h9fcGzNi3dwTK1KTaNZ4pKRp8E9w0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version: In-Reply-To:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=q01z2q70uBCSgJYAVR+vis46yH2U6fCb9IpR1jV5kvA=; b=POPRxNdAplSBsWmjki5xF0tDlU NrF59OZQR75mTle8CTZ8odi9wLuWZvIw8FNBzDA2Ysi0FtJyK2HLxdACL9LkEZvtODC69wgSeNX4D 4MXcc9WVG4bEF3BK1PNdwtsB/AGeU8EimzjBaFRnsTrZIMbOJvIDyesfbIn8FlHdWpy0=; Received: from mail-pj1-f73.google.com ([209.85.216.73]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.95) id 1v1mmS-0004ch-B7 for linux-f2fs-devel@lists.sourceforge.net; Thu, 25 Sep 2025 14:17:08 +0000 Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-32eb18b5659so1007942a91.2 for ; Thu, 25 Sep 2025 07:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1758809822; x=1759414622; darn=lists.sourceforge.net; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=q01z2q70uBCSgJYAVR+vis46yH2U6fCb9IpR1jV5kvA=; b=ldwSEwz04cXxUYsoQimJpSgwnW68SLWtXD/Ab7eol+r43v3gHU21S56ErYln39kWQI nF46j1UW7zg4aWqM+84QMlYp4fYcPBkF6KAmBpEAoNfXStUCsL36Pv/rXZ7QWRPSYSRv QEFTjg7fG8zO/QHE8pxURmOnsL6wCggZZjqGadtZPvnqf9ZG9uC/4OA7ZVzwUH3wm7UR 8C+T/5tOplXIM7MtgOLBhP3E5qi756mkBr90s05ukBvDtUXzxHAJIHF+2pmlBxGtm0tx dXsJvo6OaLcP9Twad54en/60Ro+2+fHYrFiDNXoKRpyq7UE7Pcfyi2dUroL/R9AO90Yw Rvbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758809822; x=1759414622; 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=q01z2q70uBCSgJYAVR+vis46yH2U6fCb9IpR1jV5kvA=; b=PU3b3miYRVIKQBtZgWVkYhBMaiUH+WJffie/X8UCb74dleB6k689ha1HvaS0h4gdw9 DKIZSlrlgSDb4d9iGGTjpeaaRExipGlcrLmqPXIgXRj4BLW6Lc7BL9WRMHlG8NHu/INg s6qUKZtBt0VoDkpFSlWsG0wU7EsDPxN469ko/lPmf5/DNvBd753PWvAT+hTSgA/PLPZ0 j0hCNsqQQRZwCvuRH4BelJKJwmyZtcWSr9rTTCLwrS/ChUoIyCBy3h70HMWpc7vAm75L 91iw2FiehGoZmqB2SjmyOSOfDTsehLnDRvqSDiy6gBylLNZqJdxmFNzq9TVN32OMeIzh Ypug== X-Forwarded-Encrypted: i=1; AJvYcCVl6OF0vjnFViTuWiLY/JMM4Y1cG7+OE9chiMXUX/6ZmxLenrym5xecDeulIDV0S5D7OFlsvWp/ql8rVYPFCfSd@lists.sourceforge.net X-Gm-Message-State: AOJu0YwlwccYd5i2sRht450hoBOiEjNwIO14QHH+XCCUlLE0FNsUN44H 8Z19gnKVm7DXpRLFweYCZiyoIqXlgPxaccPxXQyJexNOZF2KTbUjbCyG/ilc2NrC2w0LE0aMKBu qxx+E1A== X-Google-Smtp-Source: AGHT+IGC7UvA+zy0Lzxdig1u574Z6HM9V6jNvtPYVpQ99Zo3hDJZ7LLoK6uH5QRKE/XipBEFnMeanJ3T9fg= X-Received: from pjbon17.prod.google.com ([2002:a17:90b:1d11:b0:32e:e06a:4668]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3143:b0:32e:1ff5:5af4 with SMTP id 98e67ed59e1d1-3342a2fe9ddmr3876418a91.35.1758809822200; Thu, 25 Sep 2025 07:17:02 -0700 (PDT) Date: Thu, 25 Sep 2025 07:17:00 -0700 In-Reply-To: Mime-Version: 1.0 References: <20250827175247.83322-2-shivankg@amd.com> <20250827175247.83322-8-shivankg@amd.com> Message-ID: To: Shivank Garg X-Headers-End: 1v1mmS-0004ch-B7 Subject: Re: [f2fs-dev] [PATCH kvm-next V11 5/7] KVM: guest_memfd: Add slab-allocated inode cache X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sean Christopherson via Linux-f2fs-devel Reply-To: Sean Christopherson Cc: jgowans@amazon.com, mhocko@suse.com, jack@suse.cz, kvm@vger.kernel.org, david@redhat.com, linux-btrfs@vger.kernel.org, aik@amd.com, papaluri@amd.com, kalyazin@amazon.com, peterx@redhat.com, linux-mm@kvack.org, clm@fb.com, ddutile@redhat.com, linux-kselftest@vger.kernel.org, shdhiman@amd.com, gshan@redhat.com, ying.huang@linux.alibaba.com, shuah@kernel.org, roypat@amazon.co.uk, matthew.brost@intel.com, linux-coco@lists.linux.dev, zbestahu@gmail.com, lorenzo.stoakes@oracle.com, linux-bcachefs@vger.kernel.org, ira.weiny@intel.com, dhavale@google.com, jmorris@namei.org, willy@infradead.org, hch@infradead.org, chao.gao@intel.com, tabba@google.com, ziy@nvidia.com, rientjes@google.com, yuzhao@google.com, xiang@kernel.org, nikunj@amd.com, gourry@gourry.net, serge@hallyn.com, amit@infradead.org, thomas.lendacky@amd.com, ashish.kalra@amd.com, chao.p.peng@intel.com, yan.y.zhao@intel.com, byungchul@sk.com, michael.day@amd.com, Neeraj.Upadhyay@amd.com, michael.roth@amd.com, bfoster@redhat.com, bharata@amd.com, josef@toxicpanda.com, Liam.Howlett@oracle.com, ackerleytng@google.com, dsterba@suse.com, viro@zeniv.linux.org.uk, jefflexu@linux.alibaba.com, jaegeuk@kernel.org, dan.j.williams@intel.com, surenb@google.com, vbabka@suse.cz, paul@paul-moore.com, joshua.hahnjy@gmail.com, apopple@nvidia.com, brauner@kernel.org, quic_eberman@quicinc.com, rakie.kim@sk.com, cgzones@googlemail.com, pvorel@suse.cz, linux-erofs@lists.ozlabs.org, kent.overstreet@linux.dev, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, pankaj.gupta@amd.com, linux-security-module@vger.kernel.org, lihongbo22@huawei.com, linux-fsdevel@vger.kernel.org, pbonzini@redhat.com, akpm@linux-foundation.org, vannapurve@google.com, suzuki.poulose@arm.com, rppt@kernel.org, jgg@nvidia.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Thu, Sep 25, 2025, Sean Christopherson wrote: > On Wed, Aug 27, 2025, Shivank Garg wrote: > > Add dedicated inode structure (kvm_gmem_inode_info) and slab-allocated > > inode cache for guest memory backing, similar to how shmem handles inodes. > > > > This adds the necessary allocation/destruction functions and prepares > > for upcoming guest_memfd NUMA policy support changes. > > > > Signed-off-by: Shivank Garg > > --- > > virt/kvm/guest_memfd.c | 70 ++++++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 68 insertions(+), 2 deletions(-) > > > > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > > index 6c66a0974055..356947d36a47 100644 > > --- a/virt/kvm/guest_memfd.c > > +++ b/virt/kvm/guest_memfd.c > > @@ -17,6 +17,15 @@ struct kvm_gmem { > > struct list_head entry; > > }; > > > > +struct kvm_gmem_inode_info { > > What about naming this simply gmem_inode? Heh, after looking through other filesystems, they're fairly even on appending _info or not. My vote is definitely for gmem_inode. Before we accumulate more inode usage, e.g. for in-place conversion (which is actually why I started looking at this code), I think we should also settle on naming for gmem_file and gmem_inode variables. As below, "struct kvm_gmem *gmem" gets quite confusing once inodes are in the picture, especially since that structure isn't _the_ gmem instance, rather it's a VM's view of that gmem instance. And on the other side, "info" for the inode is a bit imprecise, e.g. doesn't immediately make me think of inodes. A few ideas: (a) struct gmem_inode *gmem; struct gmem_file *f; (b) struct gmem_inode *gi; struct gmem_file *f; (c) struct gmem_inode *gi; struct gmem_file *gf; (d) struct gmem_inode *gmem_i; struct gmem_file *gmem_f; I think my would be for (a) or (b). Option (c) seems like it would be hard to visually differentiate between "gi" and "gf", and gmem_{i,f} are a bit verbose IMO. > > + struct inode vfs_inode; > > +}; > > + > > +static inline struct kvm_gmem_inode_info *KVM_GMEM_I(struct inode *inode) > > And then GMEM_I()? > > And then (in a later follow-up if we target this for 6.18, or as a prep patch if > we push this out to 6.19), rename kvm_gmem to gmem_file? > > That would make guest_memfd look a bit more like other filesystems, and I don't > see a need to preface the local structures and helpers with "kvm_", e.g. GMEM_I() > is analogous to x86's to_vmx() and to_svm(). > > As for renaming kvm_gmem => gmem_file, I wandered back into this code via Ackerley's > in-place conversion series, and it took me a good long while to remember the roles > of files vs. inodes in gmem. That's probably a sign that the code needs clarification > given that I wrote the original code. :-) > > Leveraging an old discussion[*], my thought is to get to this: > > /* > * A guest_memfd instance can be associated multiple VMs, each with its own > * "view" of the underlying physical memory. > * > * The gmem's inode is effectively the raw underlying physical storage, and is > * used to track properties of the physical memory, while each gmem file is > * effectively a single VM's view of that storage, and is used to track assets > * specific to its associated VM, e.g. memslots=>gmem bindings. > */ > struct gmem_file { > struct kvm *kvm; > struct xarray bindings; > struct list_head entry; > }; > > struct gmem_inode { > struct shared_policy policy; > struct inode vfs_inode; > }; > > [*] https://lore.kernel.org/all/ZLGiEfJZTyl7M8mS@google.com _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel