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 A3DC9C369A2 for ; Mon, 14 Apr 2025 18:07:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C610280070; Mon, 14 Apr 2025 14:07:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0758028005A; Mon, 14 Apr 2025 14:07:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA62A280070; Mon, 14 Apr 2025 14:07:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D002528005A for ; Mon, 14 Apr 2025 14:07:38 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 90BA8B9C50 for ; Mon, 14 Apr 2025 18:07:39 +0000 (UTC) X-FDA: 83333432238.02.1D5CC01 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) by imf01.hostedemail.com (Postfix) with ESMTP id B1B074000E for ; Mon, 14 Apr 2025 18:07:37 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="iq08rdm/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of 36E79ZwsKCMEhjrlysl50unnvvnsl.jvtspu14-ttr2hjr.vyn@flex--ackerleytng.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=36E79ZwsKCMEhjrlysl50unnvvnsl.jvtspu14-ttr2hjr.vyn@flex--ackerleytng.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744654057; a=rsa-sha256; cv=none; b=aY8rWpJrEWGNcNMMz+bdbUt4ebIFl0vxjScUOtmrc43eEncy7W6CNttmUdq5kgE6oSWyXf V1W1egBVS4DzYRf4jNRM08O6e+7HhLAcSL9Picsq8YduLOKpvyMgQ+lUW0XT380G9nQNHV Wj0dYkG8I4vxeq2EWyf1IS2n7Kx/pZ0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="iq08rdm/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of 36E79ZwsKCMEhjrlysl50unnvvnsl.jvtspu14-ttr2hjr.vyn@flex--ackerleytng.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=36E79ZwsKCMEhjrlysl50unnvvnsl.jvtspu14-ttr2hjr.vyn@flex--ackerleytng.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744654057; 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=++SDvb35prT8wUX8KJx52I0lAjlJYxZ6ukgi+YkcMGk=; b=qyQrdSCr7Y+7jOA/hEYXp14BArB1bl1zndrIw+5B9GrdyBe/Cj43zeFLRM8HWPq6gS2JEK ouALRKpMCHB9ru4jMf0BgPQHIPhr0oHJa7vcoGaqvZgQdfCUByyMoYvn19LhDCbk1rFwsB P04OcSDI79fKNtjCa5oH+t1td+q/Mw0= Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-22651aca434so36766905ad.1 for ; Mon, 14 Apr 2025 11:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744654056; x=1745258856; 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=++SDvb35prT8wUX8KJx52I0lAjlJYxZ6ukgi+YkcMGk=; b=iq08rdm/qqVlIxQonFRO1lkHC8HHqO1gvkw+ocGnphoMM9k7WOQEQxgbkSHQhOpyHi bbQzU9LV6JjtYpigFXkyI+uZRP2K2EB49uGE4gtWb7EQiHzUhPH5vNr5QQfXm0+kAg/b pB7iW9/FlkGPvzROLtXc1X/OwjNJZPMIA1wdfsQBdKcONj1UOq679+/pil6ORiBDEoMG ytxHS/kuKYdlNg5W98dWSfjHISMZKc5mnzWI3qsjFbRJc+QIvT6Sq0/7bmQAj67dsZlL RPIywinQ/w6YKD9h2BI2JI6TxFYBfVun5en4XL/ONg9YdfTv8trN2CvgX0nl0A1vcR+Q 19GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744654056; x=1745258856; 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=++SDvb35prT8wUX8KJx52I0lAjlJYxZ6ukgi+YkcMGk=; b=wm0CUgVTdwYEmzZZH1zNXajziOVG3jTHuIiP9eLHW3jYU8FHXAl5qbVWPK5D65PokK olKyqT9FVEHhKRFcHK2aOut9vCVLZXVdjmtDDPsddhk+x03V3SyYbXraNy29VNyVevNj XNDHbRF5+5ptmkxE0XpMfVqYiNUFd7ZLzyzObfafp20Nffq0G/IfIXfgBuqp0LkVnFwL 22tLRJn47ET7t7QGqdFWk1W5+6PAiIWZCYZ4okBkq0St0JlqWd6gmjjLrVTQZMJAhcVY qctTBtr5NvsupcSxPxA8O0aegulHDByTEmHltaL5X6PZ67QvY7AXpGsASm8WaVkInvz5 EPZA== X-Forwarded-Encrypted: i=1; AJvYcCXwcr9wNAPvpJGk0jfucxjE2quXgr/CymJvS7tMELpjmFM6xx6SCcdv/VuOxTcUkza3bHEeYNa+BA==@kvack.org X-Gm-Message-State: AOJu0YxptZXeguZ/mDNb2quB4TKNsR4XM/84GwzJtRtFYk+9FpaJFp0I ayz/+y+NdH67dakUHtRbCra5mE/wv7EpdoHywxegzvW10/VQlNx1YCmCX6TSUmQHtYBsZBLHzzV ISMXTe4ZfG6Tl6wYhaFCJsg== X-Google-Smtp-Source: AGHT+IElXEZob++tmZ5mqeC0IBayeWoM91PrVBaN59KXtCAPwL4Hj1kJtUFwW0h4f+MctTFeOcTA04fqvlejztmSQg== X-Received: from plbkx4.prod.google.com ([2002:a17:902:f944:b0:223:69a1:46da]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:3c44:b0:224:162:a3e0 with SMTP id d9443c01a7336-22bea50dfb1mr185065455ad.49.1744654056309; Mon, 14 Apr 2025 11:07:36 -0700 (PDT) Date: Mon, 14 Apr 2025 11:07:34 -0700 In-Reply-To: <8ebc66ae-5f37-44c0-884b-564a65467fe4@redhat.com> Mime-Version: 1.0 References: <20250318161823.4005529-1-tabba@google.com> <20250318161823.4005529-5-tabba@google.com> <8ebc66ae-5f37-44c0-884b-564a65467fe4@redhat.com> Message-ID: Subject: Re: [PATCH v7 4/9] KVM: guest_memfd: Handle in-place shared memory as guest_memfd backed memory From: Ackerley Tng To: David Hildenbrand , Fuad Tabba , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org Cc: 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, mail@maciej.szmigiero.name, 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B1B074000E X-Stat-Signature: zt8dgm8fodxjtrnwywq7z5omj7ke5o9t X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1744654057-658335 X-HE-Meta: U2FsdGVkX18FKPSfAt6EIVMsFnknnPuPuT/iQGVVfkSyMD+prY+kKEppDblm8wZO/nV2xCxtSzSFdIlK1vcA2KQ41+LtNW0ypkwe9NtnOOshkYLA+ic/E93Rv+27Xo3aTpWxyRJbnxnXAvIE75Oblfg7KgOV3DMFieFhfgbiWZSYi7YZIpsGsYfLXaTcskm+swn4rX0gzdtou/tFgK03f1e8wj1wmmLw3+owg3o91+TvnHYwI3jNNlr6+gTKikZV9Fk6oVyi4ZzmG476kuaissGf+4ysnhk+iwJOYBLbfMdOHPxnx4HoFjmQdeNoEH3EdV8wMftCtzlf0qOigteAaoA3BgqCt68KDOIhXm7A3HqwaRwc8eCpbATT4IUos12gFVk62G7QdYwhPPyIiOv09zwTuUaVi0DpZL4tourELyKtoWQrq1ZZ33ky7kLvIb8S5owytU8VkgRn+jUy+f5A6sQqxwkQI1DktB3iM7LtQmCc4ztNFDPKg4zD3QfErDvCxwDQumXYDUWIlgEPcQx2dGELvvBPN9mhaZPjEzBSft4tSTiriE7yrH+3/UnryLGR2mMYtXpBmAzHUPlUUhBX7hXMsH5p1Lwa9qXFHJ2H41sryoIzhAr8sH8zIpYMQbLgBNqi2OU+GylIWDYLOp6uv5yvdj453Cl2ED0tAyjUe3T84AMROi19pDOTtsGCWAfO0/oUIm1WFPyjzPlINfd5RPhj4oykWW4cQl+ji22HK7ITy96/wo5tsVttikeI/qSUoeIra5/AFa4B6S90k3AY31aSsnLja9PqbSFEEx/LZktenirg+qWwBxFSNGmL7tIMMFTVr/dVAcCXof+WlH146BtZUe+Sb4ZLshTiVqKteTJSXJdF/xWHyX41JaHtNPB2HlVn0wgHiLWr17lIOI+CU/0A/VwakkIVI8yWq+w85zTB+5XpOTYQMG9HZ/xohR3LCztS581A+56BsZASNu5 ZfieRm+V ztNQveqhCJ32BdvMzJLaXd8wTmhfHH8CeClPITLwbK8EgJqPBnmtIHHIPMDaCqJ6dl1YxCm0pVHmgQhLUgSlzmH7WKvOMarBbkidGr+D+GsrKSEwEzjL1GW0vntqSU6RBR0HqrKDqTUEp442CkffTpMHzwROBNnNg+n3/v+kqoB5hDYXnZBi7WcmmBraqHH2JeC/mSh1lEhGgHK7rHlPrOVLsxsbdkh4vHDEBzaT2m9i3ulblDVU9ZoWX972PxK/0zaVr2ioFjbkQOQcGQK4eGEiPTmn6bz/8P+1+9IrFDafB0AwOcbW6E59BMXjoU7N2Las3iXZjy4dH/ZHYF6t7zvNDWsVU7zB2P+OBBVrdBA6bRUIpbtuS8fHsdzs11oNQRQz2GB88JcxQlSnWy+yl2gpbVWzoIjV+YmkE5+NHFuNxr0/Zl4xZEH/0gxUgEssHJbPst5DWD6sN5YOKIzPVYe78gzYu08HZIHKFpQeau/CTZTpD1GzTwX5sJytZxd00snpIq5U2jevFupKRuh1s7ebb0098/V6mz/msBD+NdfndQLtufR7lHMdm/P7YnWlIciFaQrhRL22xgejOxgK47D4+Gf5XN5HK4A0IpY8K3ncU1HfpckmsM7D4Pad9c2lNbyJa2pin4pn7nAm8xVKseHiZap71Qj0gGEzvrKQWGI6oKJ+f040MpOz4YyiqbyZq7R+DZIsK2WSHceID7Tgngm/OS1gUJVbFd57r 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: David Hildenbrand writes: > On 18.03.25 17:18, Fuad Tabba wrote: >> For VMs that allow sharing guest_memfd backed memory in-place, >> handle that memory the same as "private" guest_memfd memory. This >> means that faulting that memory in the host or in the guest will >> go through the guest_memfd subsystem. >> >> Note that the word "private" in the name of the function >> kvm_mem_is_private() doesn't necessarily indicate that the memory >> isn't shared, but is due to the history and evolution of >> guest_memfd and the various names it has received. In effect, >> this function is used to multiplex between the path of a normal >> page fault and the path of a guest_memfd backed page fault. >> >> Signed-off-by: Fuad Tabba >> --- >> include/linux/kvm_host.h | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h >> index 601bbcaa5e41..3d5595a71a2a 100644 >> --- a/include/linux/kvm_host.h >> +++ b/include/linux/kvm_host.h >> @@ -2521,7 +2521,8 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) >> #else >> static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) >> { >> - return false; >> + return kvm_arch_gmem_supports_shared_mem(kvm) && >> + kvm_slot_can_be_private(gfn_to_memslot(kvm, gfn)); >> } >> #endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */ >> > > I've been thinking long about this, and was wondering if we should instead > clean up the code to decouple the "private" from gmem handling first. > Thank you for making this suggestion more concrete, I like the renaming! > I know, this was already discussed a couple of times, but faking that > shared memory is private looks odd. > > I played with the code to star cleaning this up. I ended up with the following > gmem-terminology cleanup patches (not even compile tested) > > KVM: rename CONFIG_KVM_GENERIC_PRIVATE_MEM to CONFIG_KVM_GENERIC_GMEM_POPULATE > KVM: rename CONFIG_KVM_PRIVATE_MEM to CONFIG_KVM_GMEM > KVM: rename kvm_arch_has_private_mem() to kvm_arch_supports_gmem() > KVM: x86: rename kvm->arch.has_private_mem to kvm->arch.supports_gmem > KVM: rename kvm_slot_can_be_private() to kvm_slot_has_gmem() Perhaps zooming into this [1] can clarify a lot. In kvm_mmu_max_mapping_level(), it was bool is_private = kvm_slot_has_gmem(slot) && kvm_mem_is_private(kvm, gfn); and now it is bool is_gmem = kvm_slot_has_gmem(slot) && kvm_mem_from_gmem(kvm, gfn); Is this actually saying that the mapping level is to be fully determined from lpage_info as long as this memslot has gmem and A. this specific gfn is backed by gmem, or B. if the specific gfn is private? I noticed some other places where kvm_mem_is_private() is left as-is [2], is that intentional? Are you not just renaming but splitting out the case two cases A and B? [1] https://github.com/davidhildenbrand/linux/blob/ac8ae8eb494c3d5a943a4a44c0e9e34b4976895a/arch/x86/kvm/mmu/mmu.c#L3286 [2] https://github.com/davidhildenbrand/linux/blob/ac8ae8eb494c3d5a943a4a44c0e9e34b4976895a/arch/x86/kvm/mmu/mmu.c#L4585 > KVM: x86: generalize private fault lookups to "gmem" fault lookups > > https://github.com/davidhildenbrand/linux/tree/gmem_shared_prep > > On top of that, I was wondering if we could look into doing something like > the following. It would also allow for pulling pages out of gmem for > existing SW-protected VMs once they enable shared memory for GMEM IIUC. > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 08eebd24a0e18..6f878cab0f466 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -4495,11 +4495,6 @@ static int kvm_mmu_faultin_pfn_gmem(struct kvm_vcpu *vcpu, > { > int max_order, r; > > - if (!kvm_slot_has_gmem(fault->slot)) { > - kvm_mmu_prepare_memory_fault_exit(vcpu, fault); > - return -EFAULT; > - } > - > r = kvm_gmem_get_pfn(vcpu->kvm, fault->slot, fault->gfn, &fault->pfn, > &fault->refcounted_page, &max_order); > if (r) { > @@ -4518,8 +4513,19 @@ static int __kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu, > struct kvm_page_fault *fault) > { > unsigned int foll = fault->write ? FOLL_WRITE : 0; > + bool use_gmem = false; > + > + if (fault->is_private) { > + if (!kvm_slot_has_gmem(fault->slot)) { > + kvm_mmu_prepare_memory_fault_exit(vcpu, fault); > + return -EFAULT; > + } > + use_gmem = true; > + } else if (kvm_slot_has_gmem_with_shared(fault->slot)) { > + use_gmem = true; > + } > > - if (fault->is_private) > + if (use_gmem) > return kvm_mmu_faultin_pfn_gmem(vcpu, fault); > > foll |= FOLL_NOWAIT; > > > That is, we'd not claim that things are private when they are not, but instead > teach the code about shared memory coming from gmem. > > There might be some more missing, just throwing it out there if I am completely off. > > -- > Cheers, > > David / dhildenb