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 22B91C282D0 for ; Tue, 4 Mar 2025 08:58:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E5486B0088; Tue, 4 Mar 2025 03:58:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8953F6B0089; Tue, 4 Mar 2025 03:58:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 735A7280001; Tue, 4 Mar 2025 03:58:33 -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 57AAE6B0088 for ; Tue, 4 Mar 2025 03:58:33 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CFAA2C1905 for ; Tue, 4 Mar 2025 08:58:32 +0000 (UTC) X-FDA: 83183267664.08.C7B4923 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf16.hostedemail.com (Postfix) with ESMTP id 98503180004 for ; Tue, 4 Mar 2025 08:58:30 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Wa1o4Ods; spf=none (imf16.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741078710; 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=RU9YkTXlIz6wrxtDU3sjOBQvY5sMJ3GO7b5jBr7EI50=; b=EIqufvQb6/w1fxBmS/DFpFSIplt0GWLaYmbNd44PB1t1RLPZjRwNZXwi45Y6hR34PxxzwN rIL2uxHhscxACsbu4OULUPRDeg79M5eOTsqkaF07XCdCyPD8FA9K0sUWiLDQxg2mX5pgnl qjwmg1mkjlXHkxcEveQX5sMnX+PyFwE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Wa1o4Ods; spf=none (imf16.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741078710; a=rsa-sha256; cv=none; b=7XQWmcutP6LmC3VZ0I+lcJX9T9qxeds0ooKwkDvTRMJNVM8SbMDRcqVwMW95MsqYYspjcw 6H6kUDibal9Z+2rgyFvIqn0VXFV9X4KBeRCw3Z07rq0DGad88jswqVLuYMs99AK7vTQXMI spZaAzvxCBP244MEX42GKU0QPWybq/A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741078711; x=1772614711; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=+Rvj17kOTh2FpRb4oCsHlapbTzPh8IIrAuc3/0o8fKg=; b=Wa1o4OdsyvJMYYJsUutKKBwgHCTRvT7rPPSPqnqBUN7xpJP+vKTxRFa2 RNe/fGMj+mfmpmU+xLy9uDrfpHDSMnXwg2bp2MpnJa7TpQPLtaePCIlr8 Yma6XuU7QBI7IPpoAQtVGhKgnNCOc662NNOY9K2dAuDeTYOk+ygzImX9q g54VbSezpHzAuJRodVIVw4JhnFsy9SBoAUqBIL43CwS0BojzvpECmBDX3 +A0aOidPyVOow1/W/lW2O4VwMBPbwFsz3SKwflWbG5O+Yvqkgno05LfVr //aACyhAZbW6V3kaj904rU1kUzWwHze8KyMQx36Ya1gRQyckiky4QpETV w==; X-CSE-ConnectionGUID: 0I7qmgKsR4eNL7eBp59uzw== X-CSE-MsgGUID: M1eQk2ZfRo+K1DZe/ESrbQ== X-IronPort-AV: E=McAfee;i="6700,10204,11362"; a="64431904" X-IronPort-AV: E=Sophos;i="6.13,331,1732608000"; d="scan'208";a="64431904" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2025 00:58:30 -0800 X-CSE-ConnectionGUID: ymI/5ycUQQ+541DbD87gug== X-CSE-MsgGUID: 6kUsJMgATH6tepBDvGWyUA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,331,1732608000"; d="scan'208";a="118323391" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa006.jf.intel.com with ESMTP; 04 Mar 2025 00:58:18 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id C5A6518F; Tue, 04 Mar 2025 10:58:16 +0200 (EET) Date: Tue, 4 Mar 2025 10:58:16 +0200 From: "Kirill A. Shutemov" To: Fuad Tabba 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, 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, 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 Subject: Re: [PATCH v5 3/9] KVM: guest_memfd: Allow host to map guest_memfd() pages Message-ID: References: <20250303171013.3548775-1-tabba@google.com> <20250303171013.3548775-4-tabba@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250303171013.3548775-4-tabba@google.com> X-Stat-Signature: s44ri6y1ofiiyppd65wxztdmir8muz4y X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 98503180004 X-Rspam-User: X-HE-Tag: 1741078710-451422 X-HE-Meta: U2FsdGVkX1+eBrGUQQlbFbne3YAuOcEbeys8sThrZekRTfjua1YB0QwVsItQ/6fMA8x67lE2K5Qg1L9BAwU2fJMtJljw5Dk8ShPp4Cb9ETskXT8jNs4suM4GRJv5pYJUrcesUQqXw88B5XjGOnOZvPXUD+ob/s0stSIyx6QDLFGcwqa2JF8Pm6xMgSyGJr5xvUG2nXDGSz1YcwqCPhOb2v0YfHFgJze3kxUGMGPVKDSBcXW958H3e4ERGFqXLF0hJfle2lJVKgTDXcegRVP2e6HD0roJWaYkm6j22JXCHsUkwlnjjQUu8u4jbToNQctEhsgNyTf6Eqooq8HxMoxOPygoB8RqLDTRrfm+RxqVe1Cat93E4vQiVtEJn3UAlyTRVNAHKlzZ4C6+13Ya7vh2cXCQIF1i/M1GX/z6CN00TYuoFEPG+Mk2yVe0ayaETls5Us6CsC4tErkAZjMGTi5mtwTXb/OWPNAi2q9ETdLbQUoOwl2VDlisr4CSmKNOMquPbT7Dpqvtrg3nixx1DoDfDx3WAG5Skm4eVxN3o/W2wQHtTFy8HVkoIB8ljzSr1AJ0WYhegAf/gOjQw4KNocKi/hTzrWc8lyecJn+jX3arRRQeQr5bX3weJp94Vt9o73gtyabEBzGJqRyWLTsobfxbRSYwZwV6O4CyIZbAMZqOA0Fn5OFgUMq5xyzgBvQ6SVTWC+05F617yW5uqkMVQKbYDcCryxRi91IgWXzZxif2pqWhJJNvtGtbYABYkSC4Z69L+EV18fTzMoe6DJQQprBFzWmeHhtAeqPbJxMojOkhsO86NauMwernrzfdzR3bwIXNV7h8Na9tMYCig4CG9+XNODZVAlBNJNwETO+3Y3bTukmHVfOqxnWZsZFty8vp8R9gKhHMrE5d2ccpt0PRvvupfH4+QUP8xEIdWy/16WDxiF1iMDE1rqX9eNXSj/gQZJNYXHEC+C4fgutki0I4d0a qEf2hVTR b/OdaV0QQFTMLx9D22mrtN8sE/mH+YrNvFxWN7ONkNjtciNOpD8IXkVS2RPIOSNlK6qkrC0wQwrb0TfNkPimJX/QZOPRj98jlehglp6KxivDYyNIe3qIxZ08z0qt/Mg4X/Zk3Xki47VxrTZ1oTZohQt+16pgBXyha6BGqlYQ1jEYamDOD5Zo+bnGVjzVTCXdDiQboFTxRY9Wj/rauYz8ognhYLwT8Uu9zvRnW3OOmPsIsA10c6yA5VdibA0fHoV1f3cMzjQ/XDfrufKncORVFaToIkC5zqs5W9ixc9MBFKAfWrvLUCU/EVN5pRk9s8zX8qHPKYcqn0OoCXjU= 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 Mon, Mar 03, 2025 at 05:10:07PM +0000, Fuad Tabba wrote: > Add support for mmap() and fault() for guest_memfd backed memory > in the host for VMs that support in-place conversion between > shared and private. To that end, this patch adds the ability to > check whether the VM type supports in-place conversion, and only > allows mapping its memory if that's the case. > > Also add the KVM capability KVM_CAP_GMEM_SHARED_MEM, which > indicates that the VM supports shared memory in guest_memfd, or > that the host can create VMs that support shared memory. > Supporting shared memory implies that memory can be mapped when > shared with the host. > > This is controlled by the KVM_GMEM_SHARED_MEM configuration > option. > > Signed-off-by: Fuad Tabba > --- > include/linux/kvm_host.h | 11 ++++ > include/uapi/linux/kvm.h | 1 + > virt/kvm/guest_memfd.c | 105 +++++++++++++++++++++++++++++++++++++++ > virt/kvm/kvm_main.c | 4 ++ > 4 files changed, 121 insertions(+) > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index 7788e3625f6d..2d025b8ee20e 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -728,6 +728,17 @@ static inline bool kvm_arch_has_private_mem(struct kvm *kvm) > } > #endif > > +/* > + * Arch code must define kvm_arch_gmem_supports_shared_mem if support for > + * private memory is enabled and it supports in-place shared/private conversion. > + */ > +#if !defined(kvm_arch_gmem_supports_shared_mem) && !IS_ENABLED(CONFIG_KVM_PRIVATE_MEM) Hm. Do we expect any caller for !CONFIG_KVM_PRIVATE_MEM? > +static inline bool kvm_arch_gmem_supports_shared_mem(struct kvm *kvm) > +{ > + return false; > +} > +#endif > + > #ifndef kvm_arch_has_readonly_mem > static inline bool kvm_arch_has_readonly_mem(struct kvm *kvm) > { ... > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > index b2aa6bf24d3a..4291956b51ae 100644 > --- a/virt/kvm/guest_memfd.c > +++ b/virt/kvm/guest_memfd.c > @@ -312,7 +312,112 @@ static pgoff_t kvm_gmem_get_index(struct kvm_memory_slot *slot, gfn_t gfn) > return gfn - slot->base_gfn + slot->gmem.pgoff; > } > > +#ifdef CONFIG_KVM_GMEM_SHARED_MEM > +static bool kvm_gmem_offset_is_shared(struct file *file, pgoff_t index) > +{ > + struct kvm_gmem *gmem = file->private_data; > + > + /* For now, VMs that support shared memory share all their memory. */ > + return kvm_arch_gmem_supports_shared_mem(gmem->kvm); > +} > + > +static vm_fault_t kvm_gmem_fault(struct vm_fault *vmf) > +{ > + struct inode *inode = file_inode(vmf->vma->vm_file); > + struct folio *folio; > + vm_fault_t ret = VM_FAULT_LOCKED; > + > + filemap_invalidate_lock_shared(inode->i_mapping); > + > + folio = kvm_gmem_get_folio(inode, vmf->pgoff); > + if (IS_ERR(folio)) { > + switch (PTR_ERR(folio)) { > + case -EAGAIN: > + ret = VM_FAULT_RETRY; > + break; > + case -ENOMEM: > + ret = VM_FAULT_OOM; > + break; > + default: > + ret = VM_FAULT_SIGBUS; > + break; > + } > + goto out_filemap; > + } > + > + if (folio_test_hwpoison(folio)) { > + ret = VM_FAULT_HWPOISON; > + goto out_folio; > + } > + > + /* Must be called with folio lock held, i.e., after kvm_gmem_get_folio() */ If this is a requirement, it would be cleaner to rename the function and pass down the folio and check the lock state inside. -- Kiryl Shutsemau / Kirill A. Shutemov