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 6E091C77B7F for ; Tue, 24 Jun 2025 11:58:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E29256B00B2; Tue, 24 Jun 2025 07:58:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD8E76B00B6; Tue, 24 Jun 2025 07:58:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA1366B00B9; Tue, 24 Jun 2025 07:58:56 -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 B38D76B00B2 for ; Tue, 24 Jun 2025 07:58:56 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 722A9805A5 for ; Tue, 24 Jun 2025 11:58:56 +0000 (UTC) X-FDA: 83590147872.01.1679AEC Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf22.hostedemail.com (Postfix) with ESMTP id 9CE18C0013 for ; Tue, 24 Jun 2025 11:58:54 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="L/RMHP5T"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of tabba@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750766334; a=rsa-sha256; cv=none; b=L+4iTaUIb1dXesPjpV4S6JHL1CnM+l4rP9px59v9lBsYsNPn3eKTrU4OiIRXtejinfqgSM xVVZhozQlVYIwO/nWSFURrSEzrSm1sfg+41LO2pFQ3+6zrKDkz2HGYftjiWjcR8JfaGHxV RmstJdbivGobQO9uGCZBNbxO0FoH0rA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="L/RMHP5T"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of tabba@google.com designates 209.85.160.180 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=1750766334; 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=zAkKzBT9Oi47cUQVFAqBKpPqCgRXO9n1TGoSSjrcRig=; b=ixiLVnzAdSJDQdAHpwNrPOS+3BqFuwQanM0Y0E34ekV78s4rdNT3XaY1oP7CMPFquulsK1 pLcW7REb6KabiX57wbFh363h03WGyGVLWbK/6cJrW8tVr4cHTfjn824cPxgOLU2ShK3OlA rc4dGHsDDBWCTsfm8zvwMZB+WjsFrIw= Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-4a58ef58a38so146231cf.0 for ; Tue, 24 Jun 2025 04:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750766333; x=1751371133; 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=zAkKzBT9Oi47cUQVFAqBKpPqCgRXO9n1TGoSSjrcRig=; b=L/RMHP5T+muL3G7+jOepXCikRVOLDjawwbkE2ynvGcpzrsemvIg6dWbbp1K8y/Lx9N /I0LS/KZpmol4hOD67mpSJf5GwHntU7wD1sekpdwC47jusL+32ZstSTWMWz32nl/Kc2K 33ydsobBoAOEr6ZGlJRI/GXG7H0U6Mk1OGrAkD6JCzvSloGtrknQ0NimwaQJlbla8af4 aye8CskqumxUb0/t4RmjJzcsCQEePhuAceOc903JotI/a0zfTVe4HaTBsYG9wTLILD3A bzQyujLRyMgh3flkcfxD52Cujm+4EVTmc5zVyUAD7yESfARINtPr0hqDL4tBn0U0ztVP 0kuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750766334; x=1751371134; 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=zAkKzBT9Oi47cUQVFAqBKpPqCgRXO9n1TGoSSjrcRig=; b=NeTRF8W5SXDdzKL0QsfIZQZev/OKjr0bukXD/5uZJtQOdag2hu3Zj8iPK2KlbA5jWl eWb4rHu512Zx19Xn4fxctmmLA71XSxrR/aUYOgu70FCQhe3xQqyhRFU1bAG/WK7v8rZq ABaMHWbg40srWJS5Qn0A1SlW/0IyS75pLIQ8UhSTCAg+hkEV7q0rLOKb7TypJcv3w/TE FCScywSgGiLYTY9PVgSRz//C/gKsEypumIABNlIvp1cF3mindgieIBFz9SrVYKDpQGnJ W52W8vUUGEDvIAoJ5STowTEdsKYhLMYkMzRupqFW0pUwaPJLm0ikBTZ5Rr0eEg+OdrRx E3Sg== X-Forwarded-Encrypted: i=1; AJvYcCVJFkql/yBAh0C2OQWeC2xxzuxGiuhKJc2FRs+fkjt0cyLkx7lNuGEM3ycg3PDKxWqQF/YUHJb11A==@kvack.org X-Gm-Message-State: AOJu0Yw8vtAmHgRNPaP01YLKOxVHTf+hDbZCZH7IN4yGhBsdmXAl1ful agCIY/38Jc1ug6hXFF5cN+zOk6wohn1ZOrXtKk3j73xPQczR5eJO/PdxVf5x+zmsupClLNd5fKI QwY9i7j8V65dEye9XEy/4vDOxTQH7C7Jf0kyt5gYg X-Gm-Gg: ASbGncub0BIH3fb70UkCUs2Rg1vjSQu2paLM5zYIaGD8cJA80Utn2agHCFr46PMPjIt Kfs0UjuPSmAW1CrN6RBwEJi2L9HzSCvWQsMTg/jbh1MXePoIixEjUs/MYh55Nk0ZXY3Y7iQ1MEr 3st7xObYAYQzAKOA25wc7g/h6DD+rerz/w56g86Y65mZDvruWno7G67yXcqVZaekaW3xAKtQ== X-Google-Smtp-Source: AGHT+IFItWaOUEnQWqkCr0iMJsyetgQtFozSIRuqtaWWAUjmia/GJg3tAAHgb8EkJpgaZINqlaKB1Ek0kcCYr/IuJ+k= X-Received: by 2002:a05:622a:1983:b0:4a7:26ba:bc2a with SMTP id d75a77b69052e-4a7b16ece18mr3011891cf.15.1750766332945; Tue, 24 Jun 2025 04:58:52 -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: <11b23ea3-cadd-442b-88d7-491bba99dabe@redhat.com> From: Fuad Tabba Date: Tue, 24 Jun 2025 12:58:16 +0100 X-Gm-Features: Ac12FXxIR7DmWnStmYreR1cKwqZETUwJ47Ed0F1LblD3zm6eL8DVUB8Z-pOLCcg 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-Stat-Signature: 9ozg7kxe1reh6zf1kr17o9t3u7quirdy X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9CE18C0013 X-HE-Tag: 1750766334-685071 X-HE-Meta: U2FsdGVkX19gdu6MTQ/J2bc2luCe91j/0yy11TuikVolF0HeQTq6FE6YwNkAektfQfKlQ90UI1RG6pxFsIMHL4X9K0GT8gFb3iIEi8eavfGmGgQdIo8ABxnPRMUTOBbRfC5z8KytNqqC2DQRmnbBsqGYKhyZDUdyl4wlveF6e13auGTe9q3z/l107GpC39KTb6b52At6Sdi05aI57ecMgxTqm4qVu0JHQAYry/l9Cu/GoO+v7pMaTZxWBd2yQZYT4M1lbvT0N9dhijPi3H5ac/KcyAQcdlagG4u7wXY1u5UZhoh2o4dIbVeSXcgcBPX+eP4lp2ppXOqdRwx8VqsAxlA1qTm+AoZmzN8ZSEDFcNG03WwMuCQ9oRgbgnH1fNyBSQfnhhizqvGXQNy5iumBBc1gQJPIUB/8M+wiR4kpezNR7/0UK6C7gez4QXVGwPxt4tdwuUESCbp6+8RVtGT2Nsw3LLavBiCwzdLUQ1pVVticHPx8HyO7xHKL9P3mg1jUlFgQBfpTiyi/Yor2Jbzh3Z4hwp45pN8x7KkTYAL2PP+ykPtkiJw+KbbLF/qobn1m2XLmNLjgFZ8ouQf4ljCsQvSVJaRCQj7nOq31POqZZBAGww5rFTeff//vNBQrZqsNI9zkQQwBfN7y7/M7UDZ2gZyTBGcgu0AYKGeYEfv34YQiq+KkKH6fuRPCUl1yFyuU91GelJVBupL5yqJW7153eHo8B7uTWVSXNn/mm9KUsdlBH5kj4VUoHZLrsFLxe37d1bm0nJKydktyknqBKvBoPhV8xID85qHM2tHqYDqLi5kWqOVt3H98eht76wiXFo5V+vDA9lhwj7YW2hO6cai+kQXji+yClys1jRQmjQKWzdMFNB5lhTfxUaKiUZushAxvWcpIHY/YIdjnZTaUwks0HRArIlRb+HymhJh0b90FPBMNRYeOTprLNhvWVOJ91ARWElcDoa+OFliszB2D/+n o3ugRMdr 2PhKDxDw98DzolEgjM4oG6AoBLFzsL2HbVWRQy0kP0S4Tm5aPoBsJOv4VWESJVlcfvLr7hLVf76yL6+7wEDE4WIAssOXrGQYEm4RHLHbRX0aIN0Y2BNtFRLoNL0HjUdyguRGZIwoIWT1+RiWQf5mm9S1vB2mdOzy+89pS7o1g3xO0wOB1oajRyTKBsZA3ZGIMrYS9KzjrlVwMg1Jgz7IgorAjv8qAFp+nOS4rAckUFvkV+mbZu6epQd1JwU863nso/ov7cyvnytX/RJURsPDCML/Wjb0CaN31sAbnCcMcLWCligZ50QC/Kwca3w5NN/6RZd/OsUYeHN1Cb06CurxFpIS+7A== 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 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 > >>> > >>> 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()? > > Yes. I think having a simple kvm_is_memslot_gmem_only() helper might > make fault handling code easier to read, though. Ack. So, with that, at least the two of us are in agreement about what needs to be done for V13. I'll wait until I hear from Sean and potentially the others before I respin. Thanks! /fuad > -- > Cheers, > > David / dhildenb >