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 8B78CC83F1B for ; Wed, 16 Jul 2025 12:14:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 168506B009B; Wed, 16 Jul 2025 08:14:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13FF06B009C; Wed, 16 Jul 2025 08:14:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 055B46B009E; Wed, 16 Jul 2025 08:14:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EA1386B009B for ; Wed, 16 Jul 2025 08:14:08 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9CE9812D81E for ; Wed, 16 Jul 2025 12:14:08 +0000 (UTC) X-FDA: 83670019776.10.D5E2996 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf02.hostedemail.com (Postfix) with ESMTP id C550380005 for ; Wed, 16 Jul 2025 12:14:06 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3MGp3U8h; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of tabba@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752668046; a=rsa-sha256; cv=none; b=koGWqVWa9JhkvDPeY3NriGBhHoS9SZ8+1LOT0p8pQV8PiQMrnLPk9ZniKV9+YfqxGDoQaY KLZQArvnl1/zj93LBff5Hhc+8IL5arzvJyAkCNGy6Bo3q6X3dvK2FdX/vLckcnkObPkUgH XuJxGRp1r2Wc+9oP/HWlFhfWZ7+7IYs= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3MGp3U8h; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of tabba@google.com designates 209.85.160.176 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=1752668046; 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=aG/7TZS+9GKIxRWop/x1+ei5MRrU7wFBpXJxkGG/wu0=; b=paw1qxFJ906mI9M/jSqCkQku+29n4YV5e+1xhqzAp2tB+tygWx8Vn24+va2SYLA4gPdXQv ZsX8ajPd3kCJERwq1z19d5y7GOffD4a/dVYStOGaAneIFsZ08R84oSQgFdyyhFhT2h8uzS 4vJFL6xOXYgv+DWznXa1aPaQiRPSDW4= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-4ab86a29c98so431291cf.0 for ; Wed, 16 Jul 2025 05:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752668046; x=1753272846; 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=aG/7TZS+9GKIxRWop/x1+ei5MRrU7wFBpXJxkGG/wu0=; b=3MGp3U8hxofO99BUBz0NcIEu/rAIyigHE/eB7JXmuyZEnFT4YWGgpu7QQdtOqwQrog qhTQAGw/Ksxcom+nXUuW0HhpfvJOFx35OFMJR+xRGqbeKUEtQbAV5JPA992EuVvp3G4n AB3A1oerQRCNzDOqZFAGOZh7oOzm4bysucE3ZQN41NQcK/aKEjpD5Qbp/fMr62v9dUYg sLPLyYsgwCC54lus2m51S0mA+Jc+IZgA+KF9oJDcCcleFdQ62p+lhvfLDbWiw0Nn0rcB bQZtpjlgsJ7fQT3GN+cQtDotLs3hdNSErmdvUtz5nNA/2X3In++pVcuxq84yLGpeRSn3 QZ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752668046; x=1753272846; 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=aG/7TZS+9GKIxRWop/x1+ei5MRrU7wFBpXJxkGG/wu0=; b=hvfD7K3xWml6IzZ6/GkoQI9KeCS9eT4+1bE7LswXY6Ie7kM45eqZ972y1n3BtSZQf3 S/VQ4aPmH8PLML/OYuPQxGUuCNyVcNyIb1ScTRdwd+9AW9O25ADlXXqExqN5DiuEjDcm L9xmH4iymTYUPg9RNp3Vu/Hok4/xO70XL8fXCi1bmCoLeFAVqm4oTTlUsYzJTU2x9WR5 jaZlh0OIZqymgrvCUSv6TXF29XJ1hy8S9hjAsG2iyo9bSJRtrE5qMSrIG68a20VclFCR dHg/MJkdU/Hku5ip4GDgwc+D7w7QQYVAg65tD/sIj6QX15CuTyXxZaAN8bT6S9y7l0qD cnag== X-Forwarded-Encrypted: i=1; AJvYcCWoiHrvJtN4aYbF8uZ6zF9oXA6XpItZ9eZMIlbo7gWhPxV3rXR9MyaJE3Rvze+1aO8SlM25ztBY7A==@kvack.org X-Gm-Message-State: AOJu0YxWtXV4Kl3O4I/+gm6BK2ehVGpEwWRtMUK/g9BwxkhxqGJi5PxH TFhJwptskGz2BwZyFly8OorgoGI3etkjbvW6V1IxY9coLMUVzgsZTQ1K4sD6NEI2LrulkaJ5oIx dmjx7f+s8mvHiraK6qWARAx4NefToDJB0x3K33zb3 X-Gm-Gg: ASbGnctTbchilDPyZLPVGOnWhdSUYOYkh1gFl6JPWQytVaJIRsI7RWCKHPqyyDtLaXQ 7H6tMtf9FaObHmpu26/JsdCNGeGJpBupwbmPEze6JI6cpJ7zsdWk8RLQqygh+7aGaFXwsAswIR3 jCoCZQw7Da62ojVH8ZEJcg5FlDWg4j/VIUTG2jBd4q0/9a7J510kru/MrgNoU2XNqDtcKmNA/R9 e2ZhuNGD343egolSkNu8i8zwTE+Mhqc/jc= X-Google-Smtp-Source: AGHT+IE9YVn0eZnxvGtCeiWdCOyAhPrHi/vRfxF0vM9xrH43ByiHOUhO/4d/xBRn5PAZVeSsErTsBb99s/2AYQflYRY= X-Received: by 2002:a05:622a:1aa0:b0:4a9:b6e1:15a with SMTP id d75a77b69052e-4ab954d8746mr2571621cf.24.1752668044950; Wed, 16 Jul 2025 05:14:04 -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:13:28 +0100 X-Gm-Features: Ac12FXxuj3h3QF7Rhx9ZguI5DX-IFwgDrQ4Jd5znL_s2tRo5HM04_E0MBe2pEsw Message-ID: Subject: Re: [PATCH v14 02/21] KVM: Rename CONFIG_KVM_GENERIC_PRIVATE_MEM to CONFIG_KVM_GENERIC_GMEM_POPULATE To: Xiaoyao Li 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, 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: rspam04 X-Rspamd-Queue-Id: C550380005 X-Stat-Signature: nry3rkxr66fexchsocmwsfc43rdbnepk X-HE-Tag: 1752668046-49147 X-HE-Meta: U2FsdGVkX18wgbZBjbeDYxD2qC0/QM/zY7E7o/maUqB+BulwIvsKFAeg3Xf7D4FuXXHYjh+SGuaOBJXcJyj9qQJqizgM65KQ0JK1v2irLhHkOZasuJ6mGc9fn6UsLlbsShcz5PVVO+ZQgtWmgPiDcyuSwDxJddkcZmlmD+T0erBiVDWvVh8jwJhLQp22+drIwLVVPwI86wDIWq/gUtUN4pKr1CRAFeArNzqrsmsIoPhP3Y6jTlMCyF09Ris2fEwAXWGtX7+2j1NV6Y5RuVpSQ5oMkx9/UAh2YQQiTDrobZFij/kYVFd5r7hp/o/1VoqSNvUgog43H5cRwrOB3ZATlnZ2+tfdVU3DQQ/KbV+ADRjzd8OuuUGzBeo0u3RuCaGdh8/yAS7x18iM5Ubq9N0duvdJmF9c+Jfm1WtZup61DsBCzioDrEfUt9YoDGTcsvpu4VXfnnywsPcS3A95Ofm3Cbi6TwCsfHTCKlhysCnTJExGLWsToaWgy6RxTkLECcGd9a41Z0t6beNLjobwgAaWJDvJ/2JK8CNFfw/vrhvr2IXpC58R/1gPjJ4lTudjyQyOfbTZML8I99b9lsUJCtvvXSuKYC8LHOoSeZ86CDkOdhTaGZDpZQsamP0cE0CWpYqFjYaMfw0mSyD+BBA6igJsUkSYyzrt5GpkT5lzduot4UJ57k0XpUJNrJhnBnqJj5pIDPmlxs05j0zVBi56sMnAf9wmw9dt1mLPOqHHd+NJ/oniwZbcKa+uNyxOFTaewEFDdXeMVJDb5qMpCYm6npwjWdVOnsTj+rqkXzex8vIw6GhKEh+MZGTLsXdf/fzwLgzC4NeLk/68uJ2wkePAfWDgBpbuvYnkASfmIBCX7dd9lFMZtfAXOGzD+zAEfUiEXhqGMojwU/2qY9WWKvPEQYWrnUAnLh6eT6qsFOoyGTWJ1w/CqHFWbup0Cdg14SY9rtE4VizgxxkAGYlhi8MOURO aFnhuItg PV5/+LJeXsq/yzwiNwGJzajpU+SgWsFqvRtOLU27mg5MTztyquCLCNO61pD1yhFIRKZcDiJoatEpJEkfs1SHkXry0WYIRgzui02SSdZZC6ToAmy2FPq3k2JTPUsmUpaO/ZzSp/xbvjIrT6NZ/Lkpvb9vpHDYP9j7KlqEiGecaxa3XmqMP9sLhOnNfH86BA4S6c3Q/gdoDRog7ziQoqCdn1fBfl0j+l+QLqtYVVt957TUsG6NOIIKdE+/CD0rBSVubVsFiX3SsYsnm14Bhkdd7N3DCink5/vA8LnnETv7hL86EIiU= 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 Xiaoyao, On Wed, 16 Jul 2025 at 13:02, 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? Isn't the below practically the same as having one patch that adds KVM_GENERIC_GMEM_POPULATE, followed by a patch that drops KVM_GENERIC_PRIVATE_MEM? Cheers, /fuad > --- > 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) > { > >