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 F2FE8C369B4 for ; Tue, 15 Apr 2025 13:51:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 16CFF2800FD; Tue, 15 Apr 2025 09:51:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F5752800BD; Tue, 15 Apr 2025 09:51:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF0EB2800FD; Tue, 15 Apr 2025 09:51:44 -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 9FE7B2800BD for ; Tue, 15 Apr 2025 09:51:44 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 48891BB6C9 for ; Tue, 15 Apr 2025 13:51:46 +0000 (UTC) X-FDA: 83336416212.30.E094261 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf12.hostedemail.com (Postfix) with ESMTP id 7049340010 for ; Tue, 15 Apr 2025 13:51:44 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=vBQ2O75d; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of tabba@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744725104; 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=2krD/FL4kAPkbUf20jwju49i4p5y6JZxMe+TikflV2I=; b=NsKI+BiloE/a54sX2Zht6EzuWgRlhgCaoWonLfS0odySb7em02HBhm+s/Pt6YwPtOBZ6EU b5d07QbjFveYBOzYul0Q5DT05asLydaoBu91CCAYg87d2uOOHp1qgmZD33x/eXR2c10ofA svEcUmJvh++ni6DABeV3CBuHa4OkQ4c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744725104; a=rsa-sha256; cv=none; b=rLEC576aROx5ALzyBRpRY3WrXFVxGPP5KPxPOLgkpqYzHRUFDfT2SU/3+0zSU5TmzpHI99 5vREjAlRIprjZASW/aQTKOYXIVirdrewwUxcqBtezDEJi4LHkrpP+/9dpTWrvPYvgrwnk0 oyjbdciMiz/bN4T1w+czxFBS9Bpdegw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=vBQ2O75d; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of tabba@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=tabba@google.com Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-47681dba807so218011cf.1 for ; Tue, 15 Apr 2025 06:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744725103; x=1745329903; 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=2krD/FL4kAPkbUf20jwju49i4p5y6JZxMe+TikflV2I=; b=vBQ2O75dGRJCeCOYVqlZIk/sOUJJdjim6TEEvLoqpfKQ/A8NOBYNohJlHqo+NVb+IC 7EKz93XiKeMyoIB9VxygHXhnjfQX3S4l7FKuUlABQmPcRdeFmjvB3vRIcipFhRfs3uMN JSa8C2l667cIPP7B7D3PknWAprpJzLti6mBRPqGTDvDG0m0nx8TpiTFBFLy2CeQSOe68 q6rDOWm1TmMQ5C6pkHSwjnm9coxhTyMmuG2LynjXeVxCoAEwu2NuHIfs4F8Psa9mZgxh C6xwF6uVslTPd8SwgsL2y3drpaGIj/CWKTR0HeC9ZqfoiJlye1qA+tMgSCWStsLbXGTf H+8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744725103; x=1745329903; 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=2krD/FL4kAPkbUf20jwju49i4p5y6JZxMe+TikflV2I=; b=wrIBllduN/8QSFKS5TQj8EIjPHj/uBjVCWa5pbjtN2BARKR6VbfvUnBLsHfqFiRIjS 5wqUImPB1wgT5+mUj7nvErl4fEiwE8FtAVU0edZ/w8Ww4+xMudEcWasWXjkCvHyhnARl 9potkhWkB+p7Tv+7b+OH+/llDqD7V1AIjuvqOE/ieNHLNpsi1icjxzB1DLk3hz+8seFg 1AAK/qT2BLAMrZuxTAAxGCm6OMAM32iO2jwEkoG5XPuqEpcqBtQPSazK7y0fkZsE3Yr0 b3vW0BaRXDHerbuODmvVmOGAHzf8VrSr+2YjovijGCw44n/Bhu64/phr7TMbB6rCa1zR B01g== X-Forwarded-Encrypted: i=1; AJvYcCVG9zF/cJgs8zUSckemD16Ah5AglgN5Ai5kqVS7Aus6uOG+m1naKDfl0kwQhvXsvAw4U1EL+4/32g==@kvack.org X-Gm-Message-State: AOJu0YzdA0ozxbDtcNGa2GHM7OxdlfqOSMzvCIviJZVKX/ikFTXuSwJ8 kD7K57tbOSIDQ5fBHNg9xsaGlVXaPdfCQcshkp1p9dPzzWWup/WgiV1nERnj5ztGMmCAEFf0qHj i7PC1rIgIgjAQ6qb+XNsL3JnCmqf0KMZJNbi1 X-Gm-Gg: ASbGncuAeY0iGdd67/OYRsZefilGCeXyryIz+6plULUyuIx5aSCM4Mg802kv4XhJmEj Vx4BdayyjwmfqzO0gn555nObctTRbmtIDqA5TlBDhgrP3sI1VNWpqA1DabZp0NdzS1YSZ+2A8jN ckpYzBJCdA+qFc/gdE/juRIV3iWRsGCckaFdLof0ZsdUe4sFuMCA== X-Google-Smtp-Source: AGHT+IFA6OpbrhGV/+VCYom9qh0Ea+gMHW+k17zS5n0TQe4PsHbTdR3GAfcG6mdLxCddo/t0QnDz7jhYKdq546yAJoo= X-Received: by 2002:ac8:7e91:0:b0:478:f8ac:8adf with SMTP id d75a77b69052e-47acac18fd5mr2766361cf.19.1744725102996; Tue, 15 Apr 2025 06:51:42 -0700 (PDT) MIME-Version: 1.0 References: <20250318161823.4005529-1-tabba@google.com> <20250318161823.4005529-5-tabba@google.com> <8ebc66ae-5f37-44c0-884b-564a65467fe4@redhat.com> <103b8afc-96e3-4a04-b36c-9a8154296426@redhat.com> In-Reply-To: <103b8afc-96e3-4a04-b36c-9a8154296426@redhat.com> From: Fuad Tabba Date: Tue, 15 Apr 2025 14:51:06 +0100 X-Gm-Features: ATxdqUF2fjyijejaIC1kw37vfGIKBpDqMF-_fucpkmSEaVbZaviAZd-hhsiO6bk Message-ID: Subject: Re: [PATCH v7 4/9] KVM: guest_memfd: Handle in-place shared memory as guest_memfd backed memory To: David Hildenbrand 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, 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-Server: rspam12 X-Rspamd-Queue-Id: 7049340010 X-Rspam-User: X-Stat-Signature: wr8gmt6z4yexj9hey9grgapqbszbsg7f X-HE-Tag: 1744725104-130329 X-HE-Meta: U2FsdGVkX19bCHNWOrGIz8KLeVmzU2rCL/+jhPeieR+5CqoyYF/F12Gqf62QJ1NWzVvNAHQk4S8PqAfC0DgdHXJPxvg61IZSZ6O8V3dBVvt+d4npIcKoD7h4TmDAaXnj/Vz5UoBt5PXzqF6O+8rzL0PaFvHdNtlHpX022FwvIVp5yqR4BjXae6ceQn8OWeSc1FQQJ1EYR0U6HXxj0cWpeKyvyIXuWd9djATO0vjoTCYn89dxpCKV+yRCe7l5KnFOc8kP1Y/PCT+xumtA3MjjBUmduQUvqt6Zw264cwxQLr+NboFzZifDjKtWTOhUcW/heKxIQ90iqFBFE+/ObVpoG1BTb1IWqqDoJ/lo7a1jK3xWR6aYvXYTYgmgJjGvT/s4pd38t41PfMvS1LkXVf5dIy4cl/XYSThornSzB+ksC/UitbqBjG36Pf+5RLvxlJNILJqUI114s75F9RPiQgMSnNaCk7bhIHycQXzxBKZmu4HMO3fyjxYbY6cJ9niAmSv2QUG/4sSvFpq4GCWpiGeRbvcYjj4HPj60s2ubOS4d7WIW7+1vpnxmYsOJgWOMMWkTv69Q8Kmvyk2FpVfnqUr6AhwjUAZjUKsmKaVS8T9XB52FGJ+31FvgplPFk7m5Fk+Fel6ybDA2J0HarG5QsQvDg0/1WdKmgX4UCRGsFxvBz7tEvST4xVexAdvLA/NZ9nsBGxQiojvskYCr8rTU0aPeTIpwFWRAOu5qPpqSz6voYFEUmOj19hNHtyWgKadllvSiL77qcyxAUc7PtGX5E1G0VbtcnSnOGHnbv1TWtQzTIuGNlhhzww9d1k7boPeKpJY+SXj3Ivh708Mhg+St8i0psZ8d6rxUrjhF7ghDYSv8pvQRSTn4mVSyHTbGvEDD2QICjlDctMnn6Z+wbus3b51OtADEzeL4s/I8eZ7wvLLTnkGxBt4RJUUyDoEnbmVz+kKwDSrenuIO2SmQpzkm/l+ cGy9PZCq iQ18PzIH7Y4eQgc+HpL11lhfEWOYNZLE8FwsH6A4rMqFBjAwq3v5fGl+EGApOfImJdyghaet46j4/FyY7YaBpla/V6CgwGGRtn6/jJwE9xf4nFYvilBO8eF2S2Lak5JSRz+D2UDFGXsxUTI8D4nhN15gHiHON+MV8PDmR+VDZALIj9EWbHZII6O/TjaP6tsjcCxChmHRuCXDO6vzoh0xlCCltq0Qv9vEUtTJvUpiGtx9SoCA1VlY4eDW5OwAsZZrdHLTkp0U1BPoAGJKEd3Og3LTwqFDowSeirHr2YY7IQpUB257JFWCKHOFDO6TrNt5OlAJyuiTBpEgUslwESXZF7G9n60QGKHFDVflzshhsKyquY0aR07skKEyL9pGz1q8fUxdg 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 David, On Mon, 14 Apr 2025 at 20:42, David Hildenbrand wrote: > > On 14.04.25 18:03, Fuad Tabba wrote: > > Hi David, > > > > On Mon, 14 Apr 2025 at 12:51, David Hildenbrand wrote: > >> > >> 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. > >> > >> I know, this was already discussed a couple of times, but faking that > >> shared memory is private looks odd. > > > > I agree. I've been wanting to do that as part of a separate series, > > since renaming discussions sometimes tend to take a disproportionate > > amount of time.But the confusion the current naming (and overloading > > of terms) is causing is probably worse. > > Exactly my thoughts. The cleanup diff I was able to come up with is not > too crazy, so it feels feasible to just include the cleanups as a > preparation for mmap() where we introduce the concept of shared memory > in guest_memfd. > > > > >> > >> 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() > >> 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. > > > > For me these changes seem to be reasonable all in all. I might want to > > suggest a couple of modifications, but I guess the bigger question is > > what the KVM maintainers and guest_memfd's main contributors think. > > I'm afraid we won't get a reply before we officially send it ... > > > > > Also, how do you suggest we go about this? Send out a separate series > > first, before continuing with the mapping series? Or have it all as > > one big series? It could be something to add to the agenda for > > Thursday. > > ... and ideally it would be part of this series. After all, this series > shrunk a bit :) True, although Ackerley is working hard on adding more things on top (mainly selftests though) :) That said, having multiple series floating around was clearly not the way to go. So yes, this will be part of this series. > Feel free to use my commits when helpful: they are still missing > descriptions and probably have other issues. Feel free to turn my SOB > into a Co-developed-by+SOB and make yourself the author. > > Alternatively, let me know and I can polish them up and we can discuss > what you have in mind (either here or elsewhere). > > I'd suggest we go full-steam on this series to finally get it over the > finish line :) Sure. I can take it over from here and bug you whenever I have any questions :) Cheers, /fuad > -- > Cheers, > > David / dhildenb >