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 7B6B8C77B7C for ; Tue, 24 Jun 2025 10:26:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A66F6B00AC; Tue, 24 Jun 2025 06:26:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27E466B00AE; Tue, 24 Jun 2025 06:26:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BAE36B00AF; Tue, 24 Jun 2025 06:26:24 -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 0D9DD6B00AC for ; Tue, 24 Jun 2025 06:26:24 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BBF2158B9B for ; Tue, 24 Jun 2025 10:26:23 +0000 (UTC) X-FDA: 83589914646.09.53E8D3B Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf26.hostedemail.com (Postfix) with ESMTP id D5050140005 for ; Tue, 24 Jun 2025 10:26:21 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4nFT99xS; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of tabba@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750760781; a=rsa-sha256; cv=none; b=fmr1vkE/XN5moTmzChtx0v1ji12913FBMMLasSmFB17TWkMy3Jo/uiBl4F0d0cG0BuQxXv DTph+PZrQ8iw9mhcZ52ft9LQH4xa0GY+RfuA9lGgNUR2dUIro+3G2HNg+YzHg/qK9U6aYl qkFA1zF0Y48zTz7CIoZGfWcJR1xlpbQ= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4nFT99xS; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of tabba@google.com designates 209.85.160.175 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=1750760781; 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=uaKxjTr2Dy9UkQ7LbzgGPeXHUMCK6nT4emjWQgyE2Gc=; b=Z7B9sNxE+cWzew/EyMUc9Qqs2iecPtbKmvWrzR2QssawdrSw7JnJqLHB4R8/V2GKjSfTFo BKslkwkw/kXOnN4wt1SX1CqIgObmjITXItgDnwTT5kC1M7xdvgy6GCMujQzWIgaaDp1Tlc XeixOUNSliqTH5HAHnFH9o8OGaPlEIY= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4a5ac8fae12so373961cf.0 for ; Tue, 24 Jun 2025 03:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750760781; x=1751365581; 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=uaKxjTr2Dy9UkQ7LbzgGPeXHUMCK6nT4emjWQgyE2Gc=; b=4nFT99xSRI/wd2aBAX9HBtLX95T7qsFXTtF0Giqf+fo1CQ379Y39Ww0IySYmhM4m9P 3XHYWPNG2lb7LwK4lNIDDYTpD965D3jOlgzD0etQer7827WN0wa0VKAvWRvWy1uDNMuI Bvi3L2a9IWEUB8WLBe/R3kpfLefr+lF2wFGd8OluatArDVoka+zfijfxd4+rm2/2fKj6 mauC5SjupRMTWdjaHnI7QjvjyTkKDYCKjBrAJtemLUgTbgrw7IrQRfa3y4JGQFEp7im7 35E1EUFzywLCueFYLgwV/3YCxbxcqmFleUeLMCBPiQIMVkS8AxI2Ij1rBhJGHRttcGq9 2Bag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750760781; x=1751365581; 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=uaKxjTr2Dy9UkQ7LbzgGPeXHUMCK6nT4emjWQgyE2Gc=; b=Pkwkda4Jo0r2HJY4fuEX7n2KwFq+SSygcGAYKZFPwZo/SuK3OG/l2dXrHVNDPDvgCY 7szeijtqZYch9tkW7TzzlKgizM9GTwDAWitdwdQbA+81G3QluM+mXkXe2sJKfJB8BoP2 wRRTWlkxuFoFAeKFBGfgypdvRpF9ex21vxj5G8MByKPvnAbGS9VRay43fS+EaH6AkPPl pcxyBZiVb+NIrBRpTdt5HPfd+Ihezqp+0qQB/ZKc118lwLZt5x/kCWM0BbBuEoIKk229 Dfpt7K1P0OWzRAkwsRzEhXrBrwbtI1uSKNAsRCTo5XDGGa7UuuumfaaW1IHUaxTehBE/ jwdg== X-Forwarded-Encrypted: i=1; AJvYcCUCo9lHZvYO25D12qF4v5rspS9AtI25LVQb+gNXJbkmuEchrDr4tWCaT+QaVYmSSVu2ccEQRWvKJA==@kvack.org X-Gm-Message-State: AOJu0Yz8kf1gj0bBVLA+Y1UCxS0CDDQ6NTGOzRlF5UJoSxMlHiox1oY9 AIr33Mt/f1EgxpnqjFVHtnC1PWxvIt7pf6BNb1A1wT4aAGQ8ZRNGjblbE4RiFZ2hajLB78zCpNX d73LOxPZFohZpdowQ6hFKfVSct/aVuWSvU6VaMy4a X-Gm-Gg: ASbGncuAb1shjn/0r70eQ5luFmuapN7Tu0egVQlSrx+82KL/lQ5LbFiXum8xJHgndrF qVFPnbmqFIRBCA5aJIMbPK9UksL46JbQ6IjPPOEU1AznPn2jhVN8zdfiqtuVRjgSxs/Ik0QcZ8a Ovyx+lKyj6dj9+Nfhat1f1AWNDb9VT4KXHwBxRkyB1fZ+w+byQlnN9OPEzqhHeNFaE8YQSnMtP X-Google-Smtp-Source: AGHT+IG7dvHk9kjVfPdNY3CE09+ALlTOMcwHOWFBP9WRHrrMEvmf41kIS7uFXbaypXOKaIBbz/ZGTrFP7IhVhX4+5X4= X-Received: by 2002:ac8:5ac2:0:b0:4a6:f9d2:b538 with SMTP id d75a77b69052e-4a7af677e68mr3881551cf.28.1750760780317; Tue, 24 Jun 2025 03:26:20 -0700 (PDT) MIME-Version: 1.0 References: <20250611133330.1514028-1-tabba@google.com> <80e062dd-2445-45a6-ba4a-8f5fe3286909@redhat.com> <372bbfa5-1869-4bf2-9c16-0b828cdb86f5@redhat.com> In-Reply-To: <372bbfa5-1869-4bf2-9c16-0b828cdb86f5@redhat.com> From: Fuad Tabba Date: Tue, 24 Jun 2025 11:25:43 +0100 X-Gm-Features: Ac12FXzp2QR2bGdUaTCduQbIoXQgEK3ZRaRgh2VOnlt_lf7nCklaqTOJp7VscJk Message-ID: Subject: Re: [PATCH v12 00/18] KVM: Mapping guest_memfd backed memory at the host for software protected VMs To: David Hildenbrand Cc: Sean Christopherson , 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, 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, pankaj.gupta@amd.com, ira.weiny@intel.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: D5050140005 X-Rspamd-Server: rspam10 X-Stat-Signature: kbuekjb8ypemzccuex1xutqwhgftjkjy X-HE-Tag: 1750760781-225917 X-HE-Meta: U2FsdGVkX19ssJv/vJXNextcxoe+A3RZsuKd0Ofs94v2zisjh5NX2AFmvLeO85OwsX15DWZYkD0NbVn1vX/uRlVQODnIq85go8Aam/tIKziwfi7yGtejflk84FG4B+mDZXC93h4iwmy/ZYmYiR9Xgtvs/5WmvU+gKxAjnkFRlVbz+5HKKDpFB366oYAvY4B5mpocg3NUoNHoFtZ3R7hHxGxip8mAyD6etqc6N2XOyGOxfCslG+pIWmr9ArSDm8AKS3DVzGpIRniRuWFiPyId+q+txE7Bc6/5i3K9qb9Qxb6WfQ9kupBZDcY04fD17cOJB/7Ng4B1j6/yQCfp7ndttPNbcSPcLdsPQ872qJzSnj4cTTCtTvabqyziBjdYdhNzKDZ615kCnTV7PLXfOj0iXMJSSAjFSg/eE+hFmzzmPEySmPiwzFYnqKVx+VwURxBS8iM78mxXJUgVRTzpNvwhznRLBgbkYstVh1fivDI1FYqj/cn5xHgTXz5R6l4EvgpsA1krVaRPsdbN7cp+kFcmnLyIAqvDMvaPx7zUbMzx8t90MCXzTf1KIKmR+fZo+v20lEGG2t7+SBbPlxeTfhY1onRRwI4AfnCVlmOrCIkw8VfwqP6BR+YkQPxtGIY9e2nJen8wsnZ3/O2nZNY08b2LpjESQrX+oOjIqoOWTMdiVs1+v/KVhWc61hoZCSqacnQSxzB1UhbScQTm5xVra1/NCITcC0/G6mrXE5cBkVdci+hG3FHtjmdmtjDFkDF+IinSgNkOuUYYdRWsH60h+xO225SCQRnPM61aPrB0TVhjnv1puh+RC4sKZARsTTqfEkjVt+Xw6Lgwk0LVWaAFeJb6Ciclux5k1wHw4HBn++ybzvLQfZJXa1bZJqcupyKJakO3Z6V/YhERrm9MdP+DN8QWtJks/nXKGKTGGSZz36Fy1lO6S0k8W+4OqzTMOFuSHAXPdRX2PFNg5XrEm3h3lF3 J8OJVPcI ogx8ZMN8F49zD+hP8O+48HpyTbJCToR5fro5xMqmj4+oltn6dJzEyuIe18h/comqw0FhoAGSCbjXliMitG7YnUIXfL+vkkW3u54RwefZGZLDw5lIaZ0X0ZETnyZkZyhOfx8cjRh+bFcjTVLlbd+HTzD1pYZFRiKooRARnucjcTI7auQ4pY8+E14EmrAFbr73WyQVxB6wiv359djW1wKgh9Omfu2xWmipxT1rY/qoOV+yltapyQMDxr41QxBOkLWyqn00+GM+j0hkUy8nQ02E3B+Gq+7RzmbnqIF0awTHnh3NcYC939vH+ckqnbW3Ugv0eeeGz2JwC1FZwp1rr8SHkCiNYPQ== 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 Tue, 24 Jun 2025 at 11:16, David Hildenbrand wrote: > > On 24.06.25 12:02, Fuad Tabba wrote: > > Hi, > > > > Before I respin this, I thought I'd outline the planned changes for > > V13, especially since it involves a lot of repainting. I hope that > > by presenting this first, we could reduce the number of times I'll > > need to respin it. > > > > In struct kvm_arch: add bool supports_gmem instead of renaming > > has_private_mem > > > > The guest_memfd flag GUEST_MEMFD_FLAG_SUPPORT_SHARED should be > > called GUEST_MEMFD_FLAG_MMAP > > > > The memslot internal flag KVM_MEMSLOT_SUPPORTS_GMEM_SHARED should be > > called KVM_MEMSLOT_SUPPORTS_GMEM_MMAP > > > > kvm_arch_supports_gmem_shared_mem() should be called > > kvm_arch_supports_gmem_mmap() > > > > kvm_gmem_memslot_supports_shared() should be called > > kvm_gmem_memslot_supports_mmap() > > > > kvm_gmem_fault_shared(struct vm_fault *vmf) should be called > > kvm_gmem_fault_user_mapping(struct vm_fault *vmf) > > > > The capability KVM_CAP_GMEM_SHARED_MEM should be called > > KVM_CAP_GMEM_MMAP > > > > The Kconfig CONFIG_KVM_GMEM_SHARED_MEM should be called > > CONFIG_KVM_GMEM_SUPPORTS_MMAP > > Works for me. > > > > > Also, what (unless you disagree) will stay the same as V12: > > > > Rename CONFIG_KVM_PRIVATE_MEM to CONFIG_KVM_GMEM: Since private > > implies gmem, and we will have additional flags for MMAP support > > Agreed. > > > > > Rename CONFIG_KVM_GENERIC_PRIVATE_MEM to > > CONFIG_KVM_GENERIC_GMEM_POPULATE > > Agreed. > > > > > Rename kvm_slot_can_be_private() to kvm_slot_has_gmem(): since > > private does imply that it has gmem > > Right. It's a little more tricky in reality at least with this series: > without in-place conversion, not all gmem can have private memory. But > the places that check kvm_slot_can_be_private() likely only care about > if this memslot is backed by gmem. Exactly. Reading the code, all the places that check kvm_slot_can_be_private() are really checking whether the slot has gmem. After this series, if a caller is interested in finding out whether a slot can be private could achieve the same effect by checking that a gmem slot doesn't support mmap (i.e., kvm_slot_has_gmem() && kvm_arch_supports_gmem_mmap() ). If that happens, we can reintroduce kvm_slot_can_be_private() as such. Otherwise, I could keep it and already define it as so. What do you think? > Sean also raised a "kvm_is_memslot_gmem_only()", how did you end up > calling that? Good point, I'd missed that. Isn't it true that kvm_is_memslot_gmem_only() is synonymous (at least for now) with kvm_gmem_memslot_supports_mmap()? Thanks, /fuad > -- > Cheers, > > David / dhildenb >