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 45CC7C0218D for ; Wed, 29 Jan 2025 10:16:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C4FCF6B00E6; Wed, 29 Jan 2025 05:16:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BFF916B00E7; Wed, 29 Jan 2025 05:16:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7891280038; Wed, 29 Jan 2025 05:16:27 -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 85A546B00E6 for ; Wed, 29 Jan 2025 05:16:27 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CB7CFB090E for ; Wed, 29 Jan 2025 10:16:02 +0000 (UTC) X-FDA: 83060083764.24.2F7AE07 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf18.hostedemail.com (Postfix) with ESMTP id BA1961C0016 for ; Wed, 29 Jan 2025 10:16:00 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YjvmOr5O; spf=pass (imf18.hostedemail.com: domain of tabba@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=tabba@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=1738145760; 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=6U2SXpqCOFEGtSvGg9hkV0+K0niYl2BidP59BfMEdR8=; b=d0arucQDVn7WM2JxZCKUO0qgU2dBC9OLwirCLHXyzNv+W7sN7Ahgp9zi80ztdqQ3wdAkaY MgwiD99oHbQGY4Zps2BPOz0Klx/r3CG/OhioKOQ//wjWLsl5U1JdBEm77CbL2cNibJx9qz T59vaAEnM/bIhhD57EKKGSCDIigSKI8= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YjvmOr5O; spf=pass (imf18.hostedemail.com: domain of tabba@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738145760; a=rsa-sha256; cv=none; b=NqWexWuRZQztUPmII/PgnogXOhmAePgZR6Kh+GaIte8oZ/OreOfptXmWFyWmN4WRhOIcBv QHcwZxKGm+h1Z8daFcsnkYepCr1jXdRXax7xGxo80u4CEKIM0NOVDgNS2M6V9XKb8027M1 IcH8DbU5qSiI6aMVc7Q1IrlV8LTrf8E= Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-467abce2ef9so501871cf.0 for ; Wed, 29 Jan 2025 02:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738145760; x=1738750560; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6U2SXpqCOFEGtSvGg9hkV0+K0niYl2BidP59BfMEdR8=; b=YjvmOr5O5SNVg6V/Nue2CP7yEC4Wx4UoPBWGzuBSqpYnzhpZ8Fg+wiYFVZV0lLg5N+ N6bIxquj37a7ncWh/vPky78S04xGV42IOGKw2Tc3kSpZv6ZBgY6y5tCqPsFpfS4bvi3C YEO87TuOBrHOh2pMnskAO1sa2b5cHLROLpcnzGd/kyv3m6a005E86rRX6TqXg+R6TODO UKeSPCtzrw3Y07U59Fug1+zA9iwC9Nne7pkMd1D62ZCZeT4D4/9yhW2byaPJswNYLdjg gb4DcRQ6iOk24F6TvSBnWgFlgvmeFqpJ+BWu4DWOOXShoX/1GVlFs6ANwi3Wl3q/CLo0 6lfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738145760; x=1738750560; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6U2SXpqCOFEGtSvGg9hkV0+K0niYl2BidP59BfMEdR8=; b=KRqf4F0K5/5tPxW1qxKorcGdvXufhdQNnbM9nashxbP9/Ag8ATqczvwMT01CDP+yNj KvDWLc6fMpFvPCLwVnDZO7MRJA4nNN0stdHOKyJBa6Lvcp8m+9zw/D5l54+OXTeBXHcv tpn1SYLspk/pz4B+4SwBJTIeDTzB+JbE8NN0Y4HUNjSjr9QaYeOPPHkiZVTw86EsRkX+ eJLJetJDAzi+ubXZ5urX2AYm31U3mjBjbGSjmEcVev2BjlSW+zt9ZYn1l6AJKJr722L1 cU00GHBaghGMbtcRtDECaD+wTvS8ZXl5savRCQ1Bj4EyQhC3BMkIbwraKqLDt6rUkGQ0 e0Hw== X-Forwarded-Encrypted: i=1; AJvYcCW9SNyKAfhSxyBqU4+CP57I6Omu3c72qhWq8arTXUzlOv+7WutS5gvj/8oZUACRMvXc5pS7K2Dbrg==@kvack.org X-Gm-Message-State: AOJu0Yz44zVoHdeuJV1cGmJW/3WipgnP7XK7Rg3u8sxwN9e5OBWsDObn fLtbRwY6ecZIqL8NsgvcH6Q+48i3X+B3e250j5JxLCTErlIVpj0OvkHYjkSaVdG6mATloatn6PK dJKtVkT1KHLoUoZaUJnOACwFAfE+gqao/7jJE X-Gm-Gg: ASbGncsihKZsrsCPpXWk+aONDG7zUKxQReBqoeZHrPMBilAVkxs2nWi0M8//0thIuDq zqm7gIp/EN+ycjrXAx5gZptXRg9628XD8IYaqXwqY4Vm23tZfU4Q8rdpyMM8vBuNIHQM/RPYM76 UHnMwk76witAI3/F94o9X7MGXeHA== X-Google-Smtp-Source: AGHT+IEM754Svn5072T3T/OhYrjVi6u8afqNrNZNeiDMMfOE/htyj8uGMMSkJxhyO/Q6OtkEtp5aWwIRGzrPrqRKdWw= X-Received: by 2002:a05:622a:1b09:b0:46c:78e4:a9cc with SMTP id d75a77b69052e-46fd280676amr2107791cf.25.1738145759555; Wed, 29 Jan 2025 02:15:59 -0800 (PST) MIME-Version: 1.0 References: <20250117163001.2326672-1-tabba@google.com> <20250117163001.2326672-5-tabba@google.com> <3e1780db-6e39-4508-8ce5-4d28771400e8@redhat.com> In-Reply-To: <3e1780db-6e39-4508-8ce5-4d28771400e8@redhat.com> From: Fuad Tabba Date: Wed, 29 Jan 2025 10:15:23 +0000 X-Gm-Features: AWEUYZm9lelCVBKVaBvZr7U_TRk8ojDzX_rnjnEo65PW-lx8H9lXqyH-4BRjatc Message-ID: Subject: Re: [RFC PATCH v5 04/15] KVM: guest_memfd: Track mappability within a struct kvm_gmem_private To: Gavin Shan Cc: kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, seanjc@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, yu.c.zhang@linux.intel.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, vannapurve@google.com, ackerleytng@google.com, mail@maciej.szmigiero.name, david@redhat.com, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, jthoughton@google.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: BA1961C0016 X-Stat-Signature: bgjyzu71g47qhdaqbqwfzf3hdk6hr8xt X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738145760-984295 X-HE-Meta: U2FsdGVkX1/Z2KifcGTalfWkflXKkFJPTAbs0x/7G+ZU1nNlMshSqMkRayWtDdA8OqXxNxLZy9sXySUlMkZZmQg5uRhTtUmaB5w08gTLq4bXsBmY8l8da7AZE/+m1A0usg999gnZbqSyYGp2nfRM1kQNdy7Ac6Ssi/NajLhIoi/t6TIdGeq0pIyjn+t3BJUw3rrLcvFrAjT88OJhqyWI7MtajZkJEHfrJt3Jm9THqHOxJy/vXD8fFon28kUcfk4j8cpW3/KvAawqyzEfEpEOleaisWBp6TqtYnEGDYjZzdyYUIgqX/OkC6i50a/ZLYYNNi6C0STjvBkk96tshRKRVMXWtYY4SBzvHuz2ofXEQs2jrx/VQc3QFviAAM0klyVzBSMI2BbevbHQxOzBUBmYAmvLn7TSb+dXWNdB1IbzUxEFBHdyC/S/nwefrX94pM4zzZGAGdZQafxrnx7ERegdVbELg9HiYvIKf7RAc/QpeMlrCNoqgWpRrPzThP2Dbdxm87bDm02JG2cHNICeKgeU+4sparvSE5WUYxkR+i/15LihhLWbdtCsFy8u2av/oCkYNPYtLBfD5jJzVtctMQQVjHRXCYl6mmJYmNs/BKEKYDJqju6jVJnW/1OGLrSemHTL6vSd8E2i49PuxH4lBZN3UQ//21ZOnDQ65xfPJ3DnNDzdubp2jmNK0ROZQ9D/siT04la8cCBxNtEHj5SKOAXSPu5q7Gnyj14lt/UtzNbTHnpKGzufnVFniiSPKrl0Qvf4WzECWLz8sHfXtQbdrpGMmiq2pbbL2viqyrq/+B90xk+ivnFFOxBvJe3g7qfiMabCeHWWENCZ2xcZzrhNgAe+EK3eFQecW9i+ehlkqpdja2MZW+HAsKDHnUr+S6UDhSc0vfsCacES2U0lgx0nkrB0ea/5EmhW9Ki+vxA00UVUst/Ny2kOsEZjN8q3052SZIcIDgUgVD025eR4vYRcLJc Jz3q6YTs /z7OhoyU1aJKmEd78JdZ4zApyp4Df1bA0kam7krJQxiPSTMOPSveru+kyPbf30ZLTpqNfflSL0CAfx73Sj1+f0GUobCHZ3UBlvfFUcOiq1O3wFLSh3gHs+oppt7LhazKmSmtIyXNTFSYx8MQyZ9cWeyJc4u9fUZXPF5Uml31HksHFnaVCxSofBrQHV/vlNbcQvAxbMObq2fKLCNVaUdTVLjJP16QDxPaMOKN+ekap02bLqMgSZoZPCuf4Xhe0FRVIS2r62+iG/F4edLZuDeptZEZOJr+CqRiQ/P5pfK1AjZEH5PslNuEaDMEBN/CW9ybj5GjlfcHstNClMWPydO9Yc+f85EK9c9lP1aI2paAfCLCmt1w= 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: Hi Gavin, On Fri, 24 Jan 2025 at 05:32, Gavin Shan wrote: > > Hi Fuad, > > On 1/18/25 2:29 AM, Fuad Tabba wrote: > > From: Ackerley Tng > > > > Track whether guest_memfd memory can be mapped within the inode, > > since it is property of the guest_memfd's memory contents. > > > > The guest_memfd PRIVATE memory attribute is not used for two > > reasons. First because it reflects the userspace expectation for > > that memory location, and therefore can be toggled by userspace. > > The second is, although each guest_memfd file has a 1:1 binding > > with a KVM instance, the plan is to allow multiple files per > > inode, e.g. to allow intra-host migration to a new KVM instance, > > without destroying guest_memfd. > > > > Signed-off-by: Ackerley Tng > > Co-developed-by: Vishal Annapurve > > Signed-off-by: Vishal Annapurve > > Co-developed-by: Fuad Tabba > > Signed-off-by: Fuad Tabba > > --- > > virt/kvm/guest_memfd.c | 56 ++++++++++++++++++++++++++++++++++++++---- > > 1 file changed, 51 insertions(+), 5 deletions(-) > > > > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > > index 6453658d2650..0a7b6cf8bd8f 100644 > > --- a/virt/kvm/guest_memfd.c > > +++ b/virt/kvm/guest_memfd.c > > @@ -18,6 +18,17 @@ struct kvm_gmem { > > struct list_head entry; > > }; > > > > +struct kvm_gmem_inode_private { > > +#ifdef CONFIG_KVM_GMEM_MAPPABLE > > + struct xarray mappable_offsets; > > +#endif > > +}; > > + > > +static struct kvm_gmem_inode_private *kvm_gmem_private(struct inode *inode) > > +{ > > + return inode->i_mapping->i_private_data; > > +} > > + > > /** > > * folio_file_pfn - like folio_file_page, but return a pfn. > > * @folio: The folio which contains this index. > > @@ -312,8 +323,28 @@ static pgoff_t kvm_gmem_get_index(struct kvm_memory_slot *slot, gfn_t gfn) > > return gfn - slot->base_gfn + slot->gmem.pgoff; > > } > > > > +static void kvm_gmem_evict_inode(struct inode *inode) > > +{ > > + struct kvm_gmem_inode_private *private = kvm_gmem_private(inode); > > + > > +#ifdef CONFIG_KVM_GMEM_MAPPABLE > > + /* > > + * .evict_inode can be called before private data is set up if there are > > + * issues during inode creation. > > + */ > > + if (private) > > + xa_destroy(&private->mappable_offsets); > > +#endif > > + > > + truncate_inode_pages_final(inode->i_mapping); > > + > > + kfree(private); > > + clear_inode(inode); > > +} > > + > > static const struct super_operations kvm_gmem_super_operations = { > > - .statfs = simple_statfs, > > + .statfs = simple_statfs, > > + .evict_inode = kvm_gmem_evict_inode, > > }; > > > > As I understood, ->destroy_inode() may be more suitable place where the xarray is > released. ->evict_inode() usually detach the inode from the existing struct, to make > it offline. ->destroy_inode() is actually the place where the associated resource > (memory) is relased. > > Another benefit with ->destroy_inode() is we're not concerned to truncate_inode_pages_final() > and clear_inode(). I see. I'll give this a try. > > > static int kvm_gmem_init_fs_context(struct fs_context *fc) > > @@ -440,6 +471,7 @@ static struct inode *kvm_gmem_inode_make_secure_inode(const char *name, > > loff_t size, u64 flags) > > { > > const struct qstr qname = QSTR_INIT(name, strlen(name)); > > + struct kvm_gmem_inode_private *private; > > struct inode *inode; > > int err; > > > > @@ -448,10 +480,19 @@ static struct inode *kvm_gmem_inode_make_secure_inode(const char *name, > > return inode; > > > > err = security_inode_init_security_anon(inode, &qname, NULL); > > - if (err) { > > - iput(inode); > > - return ERR_PTR(err); > > - } > > + if (err) > > + goto out; > > + > > + err = -ENOMEM; > > + private = kzalloc(sizeof(*private), GFP_KERNEL); > > + if (!private) > > + goto out; > > + > > +#ifdef CONFIG_KVM_GMEM_MAPPABLE > > + xa_init(&private->mappable_offsets); > > +#endif > > + > > + inode->i_mapping->i_private_data = private; > > > > The whole block of code needs to be guarded by CONFIG_KVM_GMEM_MAPPABLE because > kzalloc(sizeof(...)) is translated to kzalloc(0) when CONFIG_KVM_GMEM_MAPPABLE > is disabled, and kzalloc() will always fail. It will lead to unusable guest-memfd > if CONFIG_KVM_GMEM_MAPPABLE is disabled. Good point, thanks for pointing this out. Cheers, /fuad > > inode->i_private = (void *)(unsigned long)flags; > > inode->i_op = &kvm_gmem_iops; > > @@ -464,6 +505,11 @@ static struct inode *kvm_gmem_inode_make_secure_inode(const char *name, > > WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping)); > > > > return inode; > > + > > +out: > > + iput(inode); > > + > > + return ERR_PTR(err); > > } > > > > static struct file *kvm_gmem_inode_create_getfile(void *priv, loff_t size, > > Thanks, > Gavin >