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 3C630C83F1B for ; Wed, 16 Jul 2025 12:25:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB5DC8D0002; Wed, 16 Jul 2025 08:25:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B66B08D0001; Wed, 16 Jul 2025 08:25:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A54E98D0002; Wed, 16 Jul 2025 08:25: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 9133F8D0001 for ; Wed, 16 Jul 2025 08:25:24 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3ABAE1A03B6 for ; Wed, 16 Jul 2025 12:25:24 +0000 (UTC) X-FDA: 83670048168.11.6D9DF78 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf02.hostedemail.com (Postfix) with ESMTP id 5F7F080006 for ; Wed, 16 Jul 2025 12:25:22 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FWMrXt8O; spf=pass (imf02.hostedemail.com: domain of tabba@google.com designates 209.85.160.170 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=1752668722; a=rsa-sha256; cv=none; b=pIu54e6MFVtwCu8O5PgIVNwapLCyDJedh2E8m049wIURU7v0QtIp570cMYERH3YZ2mwpkG R6jLuqFZHqIpwRdsdVwGpK/FONIgvKvsZkfQS64XFGhNmr5JH/u0xIA6ZS7aQBepYTsdBz Xj2iyzeoG7ZpXmB+e3jFUIcG++aeb5c= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FWMrXt8O; spf=pass (imf02.hostedemail.com: domain of tabba@google.com designates 209.85.160.170 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=1752668722; 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=P9vOWQfvk67OEZXIddoGDDceH/a4WGHgT9536w839YE=; b=ZFSVJr5D8Vsm+d8Y+xm3/Mshwj03Uxm1Pw2CjqwFZVvELtAbz/7ARGNAFxpg6s/KVBZeY+ oV/svpCSBlM+dYysMCwXFWLh4jadLxnRwHpyf20H1ode3PY1o+qPEvTF3GdewkP3N9v1+U TKcnRCzlWHNEBl3gwJrYrToySwMl298= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-4ab3ad4c61fso440881cf.0 for ; Wed, 16 Jul 2025 05:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752668721; x=1753273521; 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=P9vOWQfvk67OEZXIddoGDDceH/a4WGHgT9536w839YE=; b=FWMrXt8Ow7Hz3MbnWN807q55PVAxwX026JGf+rYmwWY+9negJzG6cvYpIUvvKZRNjI /OVk3P5k+ahGXx1eJbf3QD3lkkbhzhK7saTXiJddxkPyvxfEgAKZ3NtF12ODdCXo1P4m 6ACsxwIDua2QU6cIjsZsb7TGhzdPol47dEd/2m1IcWFUIgZGHmIqNRDuBI5n0hTr0ThA 67BojmShJHLi6awiVL9R2VgKTEeODBZTrC6LhbIovy2w2slEf5hBLKdRn2iDIE5XGy37 BZb5bqdvFoZvuw/FmQurdp1GrWzA9a7SBBKZcpd1HZ8kyZox8o9TPAxM8lqxT+4aS2LK dhwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752668721; x=1753273521; 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=P9vOWQfvk67OEZXIddoGDDceH/a4WGHgT9536w839YE=; b=WEwRdC5vFtMT4oLSrGyidTqS/IEt6Rg1ML65avlsfUrNTP5y+VTVGu0LadT0WirRab ut4x+arT0JI5jq0q7H4Q1gmQIKvKLjW3A2kNOGpMXJALX1feYzpUK3Tfx3s404+lhR6k fEKs6MtQir8YYdGbmNru+DSFU/3Yzom7nhK4CVE073JidTVE133v1sRIKV89dmcoFTc5 3PfKZXq2FAe0+V23TT6jDbPcKDdlUdcbCJhdSDYRsO5QDp43MvbCAkPpiGOxD+QUpRPp mxsLx6I9iKAXDXWaUpcAgy958p4t0eGfe8Lf0AZYCyt5W4sstoD5/yE2yoNkL6Kn/KMj q6Tw== X-Forwarded-Encrypted: i=1; AJvYcCU1CSriJm+qOWrlJAbHD90O/CrazmvrcLcFOklCi2N7JKIAReb/y8CU/yhBB0i9yCnGh7xoeCtpDg==@kvack.org X-Gm-Message-State: AOJu0YxrpT6iFxFwnGoohl/zRoykBeTiTa6BeXBZ1nd3xQ6VlF9JKgPH F+Ytysy9RnAmTi/kTL5PIemVgcxDXYJhJdHgfWzDF1IPmkXDqCZrS5cdHABD1fEofBNkU5Ck55h KiImFYSmFKVBwpdvATcLXeG1UvLi9sV6bGpasKNXE X-Gm-Gg: ASbGncuAxRZIywiL2we3+qinQxptSg6iiDJu9U+AA8xvAAMwV34nsrqtGu/mUC7UcSz mmfoaDHvNbklIT2bLdvZ95zkfoQglWK97lFC+ixjzbCiB7x4q4uGYVHABI6dgBzQ9/868U9OA67 lC3Kye+yPO1uipKpOGKl1N1WOl+4S+7QzmShAVYmWd048n5lL9gZD8Fmo/A9vqsynn0l+joN+2Q uh64isuxOEjK5hk3R/zYiyQA15TTuXrp5FR0+2eBABhsA== X-Google-Smtp-Source: AGHT+IH6bUjoQ8w40IEDFjYBy3Dv0CufD96xSoUjUMk4tkbVg/wklPzfe4Mv0Koy4rNvEv6fRuw2Hc0irdObv5bPYrs= X-Received: by 2002:a05:622a:151:b0:494:4aa0:ad5b with SMTP id d75a77b69052e-4ab9539e674mr2896191cf.2.1752668720187; Wed, 16 Jul 2025 05:25:20 -0700 (PDT) MIME-Version: 1.0 References: <20250715093350.2584932-1-tabba@google.com> <20250715093350.2584932-3-tabba@google.com> <418ddbbd-c25e-4047-9317-c05735e02807@intel.com> <778ca011-1b2f-4818-80c6-ac597809ec77@redhat.com> <6927a67b-cd2e-45f1-8e6b-019df7a7417e@intel.com> <47395660-79ad-4d22-87b0-c5bf891f708c@redhat.com> In-Reply-To: From: Fuad Tabba Date: Wed, 16 Jul 2025 13:24:42 +0100 X-Gm-Features: Ac12FXz8Zm2UQNV9sio4ZrBj9GKyEj5gs20r_CCCNeFGgLSNGsCRuXWEy4xCBgI Message-ID: Subject: Re: [PATCH v14 02/21] KVM: Rename CONFIG_KVM_GENERIC_PRIVATE_MEM to CONFIG_KVM_GENERIC_GMEM_POPULATE To: David Hildenbrand Cc: Xiaoyao Li , 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, seanjc@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, 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: rspam05 X-Rspamd-Queue-Id: 5F7F080006 X-Stat-Signature: g4x5uct3a3799mrxh9pctsbtrbf6nu5n X-HE-Tag: 1752668722-143904 X-HE-Meta: U2FsdGVkX1/A7oK6YgOfxGyOrOmOEIlHniXr43S2M5Q7+eVDuLrv7d2rHEjrWHNvZ9u0eZMfUjjNoy0uCbaNSvzj5HvEiENYYllojecYDBsJwgLfSR84mIlQigJDNsGw6RPGJ2wmnR617iFaITilqKVpCE1n4fJ48fhKYvXApSEp4b8r0GvGqOvLTAH7xjRe1Eg51WEIDreaxc+sC3ilIIno1U9ZDe+YjVqhPZOwUCBs5BfhaGIMNdMsHJq3uL6bTyyVMEDfrz4Jg954br6Fa4FhaTlOmfv2z76NeIZA6F0f5xtX+2Mca7iaekXGxb1b+sjEEDCcYHBJbTiRfZ2TFKEwx//Og0A7cRGzePB48kWXX/Y0goRG9QJVYvawp0CKe6WcFzg8Sieyqkx28aTKQ6FxJaZum0QdlzeLVnZnRpDhVmUW2SNRa0IpFwbFHI4QC5aQ87bjRJxGe2O9i8R1Fe5mRRUFpn9zr/izjMv3YodqGDyZ3247CPgY1lcNdA/0/It+ZQn4L5K0L4aP57SQ3WWWXhsNE8bOpPLCiPWVkKYSLnooSUJKwCVANvhQ7bVfL6RoLd3kqKeSujNF00hEazqORaGh0MmpVCwEKoQhKsX+LY6FuYCBQTcMTJT5f6QAi7Xc2DVQsBILFnttDbvMmbM+upCD906bvw6VvUSOwkZiSlTVqqiAJnPfJNSf9tK070nMP0xw6sU5CODlQX5lUXRHBT4MR1WDXkGe737T2Hq0Jcf5qYJMMY2jJj4ZEuJTJQyHGOmzmdrxEnvqiw8R/ngLFtL5wMbXNaITU5d6p7J49h2RA+9MUviJTkRLqV5T0oLkVptAS7QY1OCbE+4Y8D94sfrw9bMUzSrYmHTasFnStgkn4WxE0opwlGv5Vxkta0F1DuWgcgDkuIr3EdOlB3SkcyPk7mg75m5OeuUUU4xBEFY7I7DTe7Z/Hr0QDVTs1Mh9C1EDJWfRbSzWna4 amgtAugc qvSxXgyaSCgLl8XexSBgF+4dosiWYP6dJ/ByrCzlB2L5fzVztQ5WJP/o0oYqTmyWWphaIEhJ6TuJuBt0+DHwFazrRJAZIxddkPFQOSzuG+zWfdbmBQhmIS4RWjPtE+Up9SbKjt6lm9GycfOQOwhLPr07XY8np6d+j/iLEzJ/RBKNIx/gO8/ocNaI+qBTj5bOrZ8dgSy52oqRBsD6LYMs8m1g+OzILND3orEsW3cCLHyCzKKpduRilhLA1EfvFgCZfPipAnsALSjCL10pDBwqtY3PHSxpBIbhpTzta3qbxjftF3VXgAHbUyn4k/hN7nDVZyinAF9u2+PaDHr4djGZZAtsjUg8pFHr26pgYj8kMkQ7FFYQ= 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 Wed, 16 Jul 2025 at 13:14, David Hildenbrand wrote: > > On 16.07.25 14:01, Xiaoyao Li wrote: > > On 7/16/2025 7:15 PM, David Hildenbrand wrote: > >> On 16.07.25 13:05, Fuad Tabba wrote: > >>> On Wed, 16 Jul 2025 at 12:02, Xiaoyao Li wrote: > >>>> > >>>> On 7/16/2025 6:25 PM, David Hildenbrand wrote: > >>>>> On 16.07.25 10:31, Xiaoyao Li wrote: > >>>>>> On 7/16/2025 4:11 PM, Fuad Tabba wrote: > >>>>>>> On Wed, 16 Jul 2025 at 05:09, Xiaoyao Li wrote: > >>>>>>>> On 7/15/2025 5:33 PM, Fuad Tabba wrote: > >>>>>>>>> The original name was vague regarding its functionality. This > >>>>>>>>> Kconfig > >>>>>>>>> option specifically enables and gates the kvm_gmem_populate() > >>>>>>>>> function, > >>>>>>>>> which is responsible for populating a GPA range with guest data. > >>>>>>>> Well, I disagree. > >>>>>>>> > >>>>>>>> The config KVM_GENERIC_PRIVATE_MEM was introduced by commit > >>>>>>>> 89ea60c2c7b5 > >>>>>>>> ("KVM: x86: Add support for "protected VMs" that can utilize private > >>>>>>>> memory"), which is a convenient config for vm types that requires > >>>>>>>> private memory support, e.g., SNP, TDX, and KVM_X86_SW_PROTECTED_VM. > >>>>>>>> > >>>>>>>> It was commit e4ee54479273 ("KVM: guest_memfd: let > >>>>>>>> kvm_gmem_populate() > >>>>>>>> operate only on private gfns") that started to use > >>>>>>>> CONFIG_KVM_GENERIC_PRIVATE_MEM gates kvm_gmem_populate() > >>>>>>>> function. But > >>>>>>>> CONFIG_KVM_GENERIC_PRIVATE_MEM is not for kvm_gmem_populate() only. > >>>>>>>> > >>>>>>>> If using CONFIG_KVM_GENERIC_PRIVATE_MEM to gate > >>>>>>>> kvm_gmem_populate() is > >>>>>>>> vague and confusing, we can introduce KVM_GENERIC_GMEM_POPULATE > >>>>>>>> to gate > >>>>>>>> kvm_gmem_populate() and select KVM_GENERIC_GMEM_POPULATE under > >>>>>>>> CONFIG_KVM_GENERIC_PRIVATE_MEM. > >>>>>>>> > >>>>>>>> Directly replace CONFIG_KVM_GENERIC_PRIVATE_MEM with > >>>>>>>> KVM_GENERIC_GMEM_POPULATE doesn't look correct to me. > >>>>>>> I'll quote David's reply to an earlier version of this patch [*]: > >>>>>> > >>>>>> It's not related to my concern. > >>>>>> > >>>>>> My point is that CONFIG_KVM_GENERIC_PRIVATE_MEM is used for selecting > >>>>>> the private memory support. Rename it to KVM_GENERIC_GMEM_POPULATE is > >>>>>> not correct. > >>>>> > >>>>> It protects a function that is called kvm_gmem_populate(). > >>>>> > >>>>> Can we stop the nitpicking? > >>>> > >>>> I don't think it's nitpicking. > >>>> > >>>> Could you loot into why it was named as KVM_GENERIC_PRIVATE_MEM in the > >>>> first place, and why it was picked to protect kvm_gmem_populate()? > >>> > >>> That is, in part, the point of this patch. This flag protects > >>> kvm_gmem_populate(), and the name didn't reflect that. Now it does. It > >>> is the only thing it protects. > >> > >> I'll note that the kconfig makes it clear that it depends on > >> KVM_GENERIC_MEMORY_ATTRIBUTES -- having support for private memory. > >> > >> In any case, CONFIG_KVM_GENERIC_PRIVATE_MEM is a bad name: what on earth > >> is generic private memory. > > > > "gmem" + "memory_attribute" is the generic private memory. > > > > If KVM_GENERIC_PRIVATE_MEM is a bad name, we can drop it, but not rename > > it to CONFIG_KVM_GENERIC_GMEM_POPULATE. > > > >> If CONFIG_KVM_GENERIC_GMEM_POPULATE is for some reason I don't > >> understand yet not the right name, can we have something that better > >> expresses that is is about KVM .. GMEM ... and POPULATE? > > > > I'm not objecting the name of CONFIG_KVM_GENERIC_GMEM_POPULATE, but > > objecting the simple rename. Does something below look reasonable? > > > --- > > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig > > index 2eeffcec5382..3f87dcaaae83 100644 > > --- a/arch/x86/kvm/Kconfig > > +++ b/arch/x86/kvm/Kconfig > > @@ -135,6 +135,7 @@ config KVM_INTEL_TDX > > bool "Intel Trust Domain Extensions (TDX) support" > > default y > > depends on INTEL_TDX_HOST > > + select KVM_GENERIC_GMEM_POPULATE > > help > > Provides support for launching Intel Trust Domain Extensions > > (TDX) > > confidential VMs on Intel processors. > > @@ -158,6 +159,7 @@ config KVM_AMD_SEV > > depends on CRYPTO_DEV_SP_PSP && !(KVM_AMD=y && CRYPTO_DEV_CCP_DD=m) > > select ARCH_HAS_CC_PLATFORM > > select KVM_GENERIC_PRIVATE_MEM > > + select KVM_GENERIC_GMEM_POPULATE > > select HAVE_KVM_ARCH_GMEM_PREPARE > > select HAVE_KVM_ARCH_GMEM_INVALIDATE > > help > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index 755b09dcafce..359baaae5e9f 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@ -2556,7 +2556,7 @@ static inline int kvm_gmem_get_pfn(struct kvm *kvm, > > int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, > > int max_order); > > #endif > > > > -#ifdef CONFIG_KVM_GENERIC_PRIVATE_MEM > > +#ifdef CONFIG_KVM_GENERIC_GMEM_POPULATE > > /** > > * kvm_gmem_populate() - Populate/prepare a GPA range with guest data > > * > > diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig > > index 49df4e32bff7..9b37ca009a22 100644 > > --- a/virt/kvm/Kconfig > > +++ b/virt/kvm/Kconfig > > @@ -121,6 +121,10 @@ config KVM_GENERIC_PRIVATE_MEM > > select KVM_GMEM > > bool > > > > +config KVM_GENERIC_GMEM_POPULATE > > + bool > > + depends on KVM_GMEM && KVM_GENERIC_MEMORY_ATTRIBUTES > > + > > config HAVE_KVM_ARCH_GMEM_PREPARE > > bool > > depends on KVM_GMEM > > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > > index b2aa6bf24d3a..befea51bbc75 100644 > > --- a/virt/kvm/guest_memfd.c > > +++ b/virt/kvm/guest_memfd.c > > @@ -638,7 +638,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct > > kvm_memory_slot *slot, > > } > > EXPORT_SYMBOL_GPL(kvm_gmem_get_pfn); > > > > -#ifdef CONFIG_KVM_GENERIC_PRIVATE_MEM > > +#ifdef CONFIG_KVM_GENERIC_GMEM_POPULATE > > long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user > > *src, long npages, > > kvm_gmem_populate_cb post_populate, void *opaque) > > { > > > > > > $ git grep KVM_GENERIC_PRIVATE_MEM > arch/x86/kvm/Kconfig: select KVM_GENERIC_PRIVATE_MEM if KVM_SW_PROTECTED_VM > arch/x86/kvm/Kconfig: select KVM_GENERIC_PRIVATE_MEM if INTEL_TDX_HOST > arch/x86/kvm/Kconfig: select KVM_GENERIC_PRIVATE_MEM > include/linux/kvm_host.h:#ifdef CONFIG_KVM_GENERIC_PRIVATE_MEM > virt/kvm/Kconfig:config KVM_GENERIC_PRIVATE_MEM > virt/kvm/guest_memfd.c:#ifdef CONFIG_KVM_GENERIC_PRIVATE_MEM > > > Why should we leave KVM_GENERIC_PRIVATE_MEM around when there are no other users? > > @fuad help me out, what am I missing? I'm not sure. Splitting it into two patches, one that introduces CONFIG_KVM_GENERIC_GMEM_POPULATE followed by one that drops CONFIG_KVM_GENERIC_PRIVATE_MEM ends up with the same result. Cheers, /fuad > -- > Cheers, > > David / dhildenb >