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 B65E5C7115C for ; Wed, 25 Jun 2025 08:01:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 214CF6B00A8; Wed, 25 Jun 2025 04:01:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EBC26B00BA; Wed, 25 Jun 2025 04:01:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 102576B00BE; Wed, 25 Jun 2025 04:01:08 -0400 (EDT) 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 F2D4D6B00A8 for ; Wed, 25 Jun 2025 04:01:07 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 94BB681AA5 for ; Wed, 25 Jun 2025 08:01:07 +0000 (UTC) X-FDA: 83593177374.10.29F9C1A Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf22.hostedemail.com (Postfix) with ESMTP id B3CD9C001D for ; Wed, 25 Jun 2025 08:01:05 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sOYQEfw7; spf=pass (imf22.hostedemail.com: domain of tabba@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750838465; 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=pkejM18C3GfrxytsVF12qg6ifmp82uJ44inAGNHh7OU=; b=VP1penJDf07MYS2XFiQgL3JP5IOcqKUBmxIqejAVJ3F2gZYmFMbk500aeEjdDyFEuyX1sC AC37JE2YjW5a6D7llKfE1zQOwvCalNrbrgBxukURU+Jh9sR3MM/1TT4zXw9CidIl8bfjBD SEd5oN9qjJyHsimTl3yocsY8SYo+xdo= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sOYQEfw7; spf=pass (imf22.hostedemail.com: domain of tabba@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750838465; a=rsa-sha256; cv=none; b=CNWYzpABADlqGXUenahs1iC99/qgZZTNv8iwYVEqfV7ovBX8Ut+ht5PskM0fB0z/X3v+6W 00zEteyjKGLKZsuOZw1chLIui0bF0PN4Ls3VlFy2ZCrckKP0fX9TvEm2WuPkpoDsfOKxtS yb3fgxJHnCBBxehRSbFC/6BY1xOuyYw= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-4a5ac8fae12so308451cf.0 for ; Wed, 25 Jun 2025 01:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750838465; x=1751443265; 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=pkejM18C3GfrxytsVF12qg6ifmp82uJ44inAGNHh7OU=; b=sOYQEfw74HxyiNgU3s9K/4yVqWbDSecuasXeWH/4bDH1b8K4h5h7MZlKX8RcEUvl+D TYCeD+vcu5rcJSvBu2ltywCCpRaMCq4U1GcI2ffga1fSKVqkIDB2u4lL+of8TSRgJ8Pj 5b1htrMsX7WvBl7WvTgWQWWRM0188dX5BI35ET4qd5zWqD6dQ71NK2Ra0P6fjxtD1d44 XYz9Ebw53U6AKnu5mhXEJMVbWuB3FoAyZ5VoHDrqAuUwNrz3nV2e2hfyZ5DVIOSMABEr MtDBMPhHW7WW1EKDgUXhe87PdNtker6pJYkcPJHvKIsppEKSdWS9wJIfCGNfErfrRmqE BpPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750838465; x=1751443265; 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=pkejM18C3GfrxytsVF12qg6ifmp82uJ44inAGNHh7OU=; b=mbj5wG3yMhP+wtFufF1UpOPF61YXTux0kysRRPY8KTJ4xVNdYS5igRBQpmCi1MNXD7 MfN2yqGKl1rIXBmP5KsPAWtG9m5JeH8u36xGBUk9UpB5RGJgUYeMbwIVkzt92+68P6Ao nkWNaHembUot2WNSil+eVL9x+KB/+Y0H7/jfpQlN0Yg5RE02Lxut+zjUKw9gbhdOzDTa war7G7Go/KLeQ3At399R8ismqZr5adp7J19Vg4+9R/Xhz/Yp8DVKh26iieVpVnKXGxyd H7SlKu3qgzbuSrQx7JzHRxZ3Ys5g3shoLUY809LV93AA3wiAblND85q5CxM3EMAS9S2j AElw== X-Forwarded-Encrypted: i=1; AJvYcCWzWOXNTIZvB8GODA5lfa7CK3vHDkAX1YOT6yorDi+zZIH307GJSAj+9e3697rtciYaPN8kgJHTKg==@kvack.org X-Gm-Message-State: AOJu0YzMd63iy5EHnqmSaGz+rGRpRoeH5nBxK7raFnVWkvC7ojNzCoHS BzW/eMgBFPrxEEgJb52SPVEgHTXmkcP7kV3qd0PuNNmy2y+mC9WYtfb6ODIRQT++7C1xpDNCGdq +uux0Tdzh1LBmKpRqOT7YCUnv+7yqxke12lAepe+J X-Gm-Gg: ASbGncvNdS+43/ik6hszzE/HNlxyxqHsfMN1ejElEcrVxXwsonsP1x6KQ4KOY9WIEey PFruEfyrwZcdO3b1iVt/amZ4R3o0jBdYBWs/qCTz0QahdbDmBXzIpiksgaQ2edGXyq/uePXFyoB PMST81IHJ1IMzBiFUmuOmLSdei5VxThugwFGUD4TunVtXvadezWYmFteSjfXbCM2kPC3LMaY2r X-Google-Smtp-Source: AGHT+IE2Z7ybLIm8G7t7Cyt3+6pzdghtibzBxlp3eQYjFPTUgErAfVsE5Z7imWnMwgGVA5CdNcPQ+V+dHuEnxerz1hc= X-Received: by 2002:a05:622a:9010:b0:4a5:9b0f:9a54 with SMTP id d75a77b69052e-4a7c2378969mr1821891cf.18.1750838464297; Wed, 25 Jun 2025 01:01:04 -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> <11b23ea3-cadd-442b-88d7-491bba99dabe@redhat.com> In-Reply-To: From: Fuad Tabba Date: Wed, 25 Jun 2025 09:00:27 +0100 X-Gm-Features: Ac12FXyOZYq0_oSfy0HtoaRPA-7sk9XG35u6SnLqNIC2Y6Zwbb2K7V88hLfiL88 Message-ID: Subject: Re: [PATCH v12 00/18] KVM: Mapping guest_memfd backed memory at the host for software protected VMs To: Sean Christopherson Cc: David Hildenbrand , 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-Server: rspam04 X-Rspamd-Queue-Id: B3CD9C001D X-Stat-Signature: zdr87hisyryicdtxjeginoageojmyy8z X-HE-Tag: 1750838465-411311 X-HE-Meta: U2FsdGVkX18bNquy4h4kNIU5xghbVVxQqEWwIokZbdedknJidhx2e+6yLxoq1zZAy7Q5HWCqjEujkCAUhguBKbxBDbz39y8noysrWQofjqLwdEoJ3gaNxaqiH+VeTNTbwBJNelGBrWTKhS/NkNRU/j3jHEhZp3qymN7owGOW7bDDiOBlFYU8zBg6ob1WJ6h4rUVyzCBSlaOMme4V3TMQlztbnpC6xOZAItoBfNK9WTQFL47Wi0sy9ijX8/OBdinmwpm248TNjEYej6d6JCu9xUyNWBAGmfkusM0Jc3MLmk1ehGGVB4Sz69kwDm0Z3P4QEXCie0rBaN0MhFsJcinf4UvPgbZ4QI6BQsMDR7bUP01v2Dj7zKifTU2tzZZTQQuT8CID4Nx33KmmE86ZSlc0UlHfzl+hlkgRm+OS8G5vI/R4vpoD7fNEvzg8vtJCtfhN7mSijEcyhImSwZEY8nbcHxeMLGjUs2ZVBf+4tZD2ZUpikSrraMcAfkj/0/1LzA1o+LtAZWeIauO18h8E4W+GdggNZI2Is2fMYtmv6dG6ErsmcRBXtiKjy2MP/n7N+yKQ1KFONFuE1S1cw3I27KOtZl6Fs672YS9N7YwKBE2/TIvTDCAGRkpgAGBlpNchcWxkwMQZWZgrlO1btEe+FBX/QMegC9m61YvzTJlGpuy8ctttZkoxOpn6opKQRqMLIqVRyA8gdESZfEkrSa6uAD+5S0CyLFtEnZLHP902geg/vuziiF19agUKI/li9O3cSaYyvonZjHCfWxR1Te9CPcrIpBRv8vplzJCeFD9bTgn8o48wi1QotDiJinsZoAcpq6cJ0sd8SRYMwwz+42Pc9W6DmBd9aGsbItcTFic6BDWVfocy/D/GSA0MStnOlG3FOt4ZEO5Pe1x6Cm5yX+0VNR4wwmUH9oJu4OWIjMkGYWmjZtj4fW5NfhZQurbPcZ9trHajdC/LSnv2paOvYOxoBkL otbJ5FqT jkvd9dDPisH3OMxmVfa/QxeaETZT6H6EVwRqwf93ONXPnYuSrvUBKRWQZjJAtjL8skUMYBWJrJn0fyKXiirFASvYn3m+3/mSrdxP4/+GHbDpl2yceySiImtToV2KQal8B1C0StDtVlbxeEfSNF43+7w4th2yy7ePhldCDBPUBkq/BblmU5zSXdqxeY3ZGiWCqn9lFv//QvOyrw9KB6dDvM81hz1OX/EyOKblZJGHf1z7nlConf5AATgsGGj/aClM8yUOxC/7Wu+XtjwRPUnhfZq7Wyg2MDJ87lqRSpA1ZcZOjy/SqWa7inKS71cQNrxh5/+nd 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: Thanks Sean, On Tue, 24 Jun 2025 at 18:50, Sean Christopherson wrote: > > On Tue, Jun 24, 2025, Fuad Tabba wrote: > > On Tue, 24 Jun 2025 at 12:44, David Hildenbrand wrote: > > > > > > On 24.06.25 12:25, Fuad Tabba wrote: > > > > 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 > > This one... > > > > >>> 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() > > ...and this one are the only names I don't like. Explanation below. > > > > >>> 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. > > Yeah, I'm fine with this change. There are a few KVM x86 uses where > kvm_slot_can_be_private() is slightly better in a vacuum, but in all but one of > those cases, the check immediately gates a kvm_gmem_xxx() call. I.e. when > looking at the code as a whole, I think kvm_slot_has_gmem() will be easier for > new readers to understand. > > The only outlier is kvm_mmu_max_mapping_level(), but that'll probably get ripped > apart by this series, i.e. I'm guessing kvm_slot_has_gmem() will probably work > out better there too. > > > > > 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()? > > > > > > Yes. I think having a simple kvm_is_memslot_gmem_only() helper might > > > make fault handling code easier to read, though. > > Yep, exactly. The fact that a memslot is bound to a guest_memfd instance that > supports mmap() isn't actually what KVM cares about. The important part is that > the userspace_addr in the memslot needs to be ignored when mapping memory into > the guest, because the bound guest_memfd is the single source of truth for guest > mappings. > > E.g. userspace could actually point userspace_addr at a completely different > mapping, in which case walking the userspace page tables to get the max mapping > size would be all kinds of wrong. > > KVM will still use userspace_addr when access guest memory from within KVM, > but that's not dangerous to the host kernel/KVM, only to the guest (and userspace > is firmly in the TCB for that side of things). > > So I think KVM_MEMSLOT_IS_GMEM_ONLY and kvm_is_memslot_gmem_only()? > > Those names are technically not entirely true, because as above, there is no > guarantee that userspace_addr actually points at the bound guest_memfd. But > for all intents and purposes, that will hold true for all non-buggy setups. Got it. So, to summarize again: In struct kvm_arch: add `bool supports_gmem` instead of renaming `bool has_private_mem` The guest_memfd flag GUEST_MEMFD_FLAG_SUPPORT_SHARED becomes GUEST_MEMFD_FLAG_MMAP The memslot internal flag KVM_MEMSLOT_SUPPORTS_GMEM_SHARED becomes KVM_MEMSLOT_GMEM_ONLY kvm_gmem_memslot_supports_shared() becomes kvm_memslot_is_gmem_only() kvm_arch_supports_gmem_shared_mem() becomes kvm_arch_supports_gmem_mmap() kvm_gmem_fault_shared(struct vm_fault *vmf) becomes kvm_gmem_fault_user_mapping(struct vm_fault *vmf) The capability KVM_CAP_GMEM_SHARED_MEM becomes KVM_CAP_GMEM_MMAP The Kconfig CONFIG_KVM_GMEM_SHARED_MEM becomes CONFIG_KVM_GMEM_SUPPORTS_MMAP What will stay the same as V12: CONFIG_KVM_PRIVATE_MEM becomes CONFIG_KVM_GMEM CONFIG_KVM_GENERIC_PRIVATE_MEM becomes CONFIG_KVM_GENERIC_GMEM_POPULATE kvm_slot_can_be_private() becomes kvm_slot_has_gmem() Thanks, /fuad