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 43A04C83F1B for ; Wed, 16 Jul 2025 08:52:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C223B8D0005; Wed, 16 Jul 2025 04:52:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD2CD8D0001; Wed, 16 Jul 2025 04:52:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC1978D0005; Wed, 16 Jul 2025 04:52:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 961A98D0001 for ; Wed, 16 Jul 2025 04:52:46 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4072E1A0310 for ; Wed, 16 Jul 2025 08:52:46 +0000 (UTC) X-FDA: 83669512332.06.5E595F8 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by imf11.hostedemail.com (Postfix) with ESMTP id A9B8140008 for ; Wed, 16 Jul 2025 08:52:43 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=GLwLjflv; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf11.hostedemail.com: domain of xiaoyao.li@intel.com designates 198.175.65.18 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752655964; a=rsa-sha256; cv=none; b=O1Q3GVNOPAxRqOAn9yUCthTaQwTYRCvjXLEhF593QQsK5LeGvnNasnlsufVuk6qfD7NdYB 5yNRWefPjZObWxSwQhHRHi93a61KD+j31dwqnR1EK0fO/ZzLw/BT1xuiwP6G/kltvuYfAQ LmAA4caXTpXhgdJfoG4aHfY37wjlmSo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=GLwLjflv; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf11.hostedemail.com: domain of xiaoyao.li@intel.com designates 198.175.65.18 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752655964; 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=Oygo69C2Rp/3Cuo9PQ7Z0ZUcCkRYupYWvh22yAwChUk=; b=cbhYcpWIxQz7bkFOJ77XXW2YDLQSDJl5xY48fD7H7k/lFILwsdPgu6q46BEAairszAre7/ +uot0b9TgpFFAkEGQeX8tC7Bxza2C5mYj092Xs02P1Cuuv60XOpyR6NrFuDLkdZMzHcASK W2R3SFkvZVWcF1MGxl8bPIgKqSHGimM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752655963; x=1784191963; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=94kf4M+XD6NApSPBMCDqmsn2ygZAgx+ZZdELWr26Y9s=; b=GLwLjflvStxM1HxaZI9WXUq6OVE9PhQka6J/3EuqwweyTTeK6bIo4PRx wXsHBBUDrs602N/vWZHRyHVjIyWVXYAXlw2ph82E+/KjwYcLP9Sz8wMxw dDlL9XrAWAOV4E5yRzA+pNkHVVEGoEsMzeN+OHiYRra0eqwWv6oM/Xbty mRgbKugEGu283TswETlkp7Zn5yhCQ9i8yx82yVpJ2qL0FZ8d6qFSFXBA8 Es1VPfMPSAyVQqzTIPQHh/LqV7uFqEvXHMxAvQdq1rPH3QjYz9nGnkciq zpp3lMIp25/u5E3X3AGznjMZIFWjYUbqIcktYm1wEg1rvQe5L4uUpTZO0 A==; X-CSE-ConnectionGUID: P+bqlP7nQ46WVcdDL7qqdA== X-CSE-MsgGUID: n758U3puQPi9DyHCZIzCAQ== X-IronPort-AV: E=McAfee;i="6800,10657,11493"; a="55013961" X-IronPort-AV: E=Sophos;i="6.16,315,1744095600"; d="scan'208";a="55013961" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jul 2025 01:52:42 -0700 X-CSE-ConnectionGUID: v3EhzNgHRDyuDzMapsSL+g== X-CSE-MsgGUID: pr/19EOUSoCs0Cadba9NhQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,315,1744095600"; d="scan'208";a="157534744" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.247.1]) ([10.124.247.1]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jul 2025 01:52:27 -0700 Message-ID: <47bc83a0-5b5b-4f00-a6d2-1e5b4486f94f@intel.com> Date: Wed, 16 Jul 2025 16:52:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v14 09/21] KVM: guest_memfd: Track guest_memfd mmap support in memslot To: Fuad Tabba Cc: kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, kvmarm@lists.linux.dev, 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, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.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, peterx@redhat.com, pankaj.gupta@amd.com, ira.weiny@intel.com References: <20250715093350.2584932-1-tabba@google.com> <20250715093350.2584932-10-tabba@google.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A9B8140008 X-Stat-Signature: 7ud347irf1gweo87eny1zhpqj4s74fsh X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1752655963-432209 X-HE-Meta: U2FsdGVkX1+HPJ6JcxdCR50zD+oR24su3Q9o8CXcPYs33oLMlVjI4Mw9XOtB2Kzn4U7wxchnfBlf8AoTD2IMQCmQDq0FmZjZPtclWEfNBuRHSRW0xtVSXFS3N1S8JtlpFqrKVgBbLijjRo9iOYWqXEH8P53XY+HJwzOHHwt8mx/AezSZA8VqZu/G7icytzxAjeI4YXdTeb6dAo9AbkyekefypixyuG9EcTQgzYyxt9bVII/io82P0zWgpBLttrG+0oacWLMs+ly2gNBz0MFP53o4vhR9hUZqHsCIpaFycwUnItg1hszyR7kO1lcSY1rzSzVzS6L64ljJL7x1V2iFALYsP4aN4lH59BE4sD+a6am76bWp4MgLw3lyDRU6uvkE8dGDxmN/wOgfaUsNa4AvnbQ6oCb4YgyF9a/dtj6tlC+Qp/veOn0OeYIW3tatJv4aqzhDxljfUN+DqrNvHwilI4wq7KqPNkcON6i4xCdqRKCVW04iGUAVYX1tb214CcwxkA9eIZIF5N0oynj3tqnyIluHKv8W6LDtGGovXnKNyrIEVt8pmhHNK97DwMD1APLVkHXmn7VZlBqG7v8H2AG8efSKVvJdGWIgRfuKxl1G0SPgmdvUocYF36HIP9ak9UnMsmzOgRAR3S3eTnbkkYq9EfQRBEDGJIcBScoTKqXc3EqbuBIOT2Y+290TtLvE5TLETEhC4oK/n06yWdCvms2pPzuLs1/rEQnw+0mun9wFvg7UWNLCdFobn2AU8CbJfyjRVkIzRK1F0Ewxc0OjPR0Xe5lXG+tR3IoRiV7Qn9D2luK0iYbLVbFYzFrya6K/A6RWro889CTEqF5zwQpQjltMoOkckjtcfUr1JwuaYRRmRUW2vNHnCw7aSOENkn1MVWSdbTfwSiDNJGAPgq7ptA8iXkq6xOD4RJXQBD8JXPJAx9CFdUiYrzdnrhbkhxXIm9siHCqVpapy7hMvxiSQ0rK AhRA5OlN 5Yt/sOBZp4DDB5DAW+eauS2VjQEwJnMi/XH7A+CSnMIarA+D+BpWMFMGS6qkI/yVZm6fCWTbIUONEGi8CkASUkZd+Xx3FPRGh+vkQcEed8sB/UyjActwbrR5n59Cq/N6A7yi9GG5XLiR66r/FK74C35htuO1JfkawUOaNMuha0MB2hJFWy2Yn3gBoMcWWF24BIpMLr7RvbP/jcv5OwyFM4FXbQcraOJt3OZr5CeesXYBhtDEj+dgN6h+GpsSAs25aiYnjJIWQcW15Cxd4/kl+futyushdQJduiRLNiz5SEI5Hn3ORD6iPzWCOODTE2+9MBg6WhrZ3u3wpQm5LzHfE0O3AA37qaMY7jtmHN9ZLudfiVHpHdKZE/OpMYNc7TgrRw+a3pAHpMvlsn8vIMlleYACX33DQ0dV3R5btnYw25TBbr30s4rO9vwhjOxAlbHeD7ZqlkVqfjC8/X7Y= 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 7/16/2025 4:21 PM, Fuad Tabba wrote: > Hi Xiaoyao, > > On Wed, 16 Jul 2025 at 07:11, Xiaoyao Li wrote: >> >> On 7/15/2025 5:33 PM, Fuad Tabba wrote: >>> Add a new internal flag, KVM_MEMSLOT_GMEM_ONLY, to the top half of >>> memslot->flags. This flag tracks when a guest_memfd-backed memory slot >>> supports host userspace mmap operations. It's strictly for KVM's >>> internal use. >> >> I would expect some clarification of why naming it with >> KVM_MEMSLOT_GMEM_ONLY, not something like KVM_MEMSLOT_GMEM_MMAP_ENABLED >> >> There was a patch to check the userspace_addr of the memslot refers to >> the same memory as guest memfd[1], but that patch was dropped. Without >> the background that when guest memfd is mmapable, userspace doesn't need >> to provide separate memory via userspace_addr, it's hard to understand >> and accept the name of GMEM_ONLY. > > The commit message could have clarified this a bit more. Regarding the > rationale for the naming, there have been various threads and live > discussions in the biweekly guest_memfd meeting . Instead of rehashing > the discussion here, I can refer you to a couple [1, 2]. I don't object the name. Just want the clarification in commit message and even better add comment in code. That will be truly helpful for future readers. > [1] https://docs.google.com/document/d/1M6766BzdY1Lhk7LiR5IqVR8B8mG3cr-cxTxOrAosPOk/edit?tab=t.0#heading=h.a15es1buok51 > [2] https://lore.kernel.org/all/aFwChljXL5QJYLM_@google.com/ > > Thanks, > /fuad > >> [1] https://lore.kernel.org/all/20250513163438.3942405-9-tabba@google.com/ >> >>> This optimization avoids repeatedly checking the underlying guest_memfd >>> file for mmap support, which would otherwise require taking and >>> releasing a reference on the file for each check. By caching this >>> information directly in the memslot, we reduce overhead and simplify the >>> logic involved in handling guest_memfd-backed pages for host mappings. >>> >>> Reviewed-by: Gavin Shan >>> Reviewed-by: Shivank Garg >>> Acked-by: David Hildenbrand >>> Suggested-by: David Hildenbrand >>> Signed-off-by: Fuad Tabba >>> --- >>> include/linux/kvm_host.h | 11 ++++++++++- >>> virt/kvm/guest_memfd.c | 2 ++ >>> 2 files changed, 12 insertions(+), 1 deletion(-) >>> >>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h >>> index 9ac21985f3b5..d2218ec57ceb 100644 >>> --- a/include/linux/kvm_host.h >>> +++ b/include/linux/kvm_host.h >>> @@ -54,7 +54,8 @@ >>> * used in kvm, other bits are visible for userspace which are defined in >>> * include/uapi/linux/kvm.h. >>> */ >>> -#define KVM_MEMSLOT_INVALID (1UL << 16) >>> +#define KVM_MEMSLOT_INVALID (1UL << 16) >>> +#define KVM_MEMSLOT_GMEM_ONLY (1UL << 17) >>> >>> /* >>> * Bit 63 of the memslot generation number is an "update in-progress flag", >>> @@ -2536,6 +2537,14 @@ static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu, >>> vcpu->run->memory_fault.flags |= KVM_MEMORY_EXIT_FLAG_PRIVATE; >>> } >>> >>> +static inline bool kvm_memslot_is_gmem_only(const struct kvm_memory_slot *slot) >>> +{ >>> + if (!IS_ENABLED(CONFIG_KVM_GMEM_SUPPORTS_MMAP)) >>> + return false; >>> + >>> + return slot->flags & KVM_MEMSLOT_GMEM_ONLY; >>> +} >>> + >>> #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES >>> static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn) >>> { >>> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c >>> index 07a4b165471d..2b00f8796a15 100644 >>> --- a/virt/kvm/guest_memfd.c >>> +++ b/virt/kvm/guest_memfd.c >>> @@ -592,6 +592,8 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot, >>> */ >>> WRITE_ONCE(slot->gmem.file, file); >>> slot->gmem.pgoff = start; >>> + if (kvm_gmem_supports_mmap(inode)) >>> + slot->flags |= KVM_MEMSLOT_GMEM_ONLY; >>> >>> xa_store_range(&gmem->bindings, start, end - 1, slot, GFP_KERNEL); >>> filemap_invalidate_unlock(inode->i_mapping); >>