From: David Hildenbrand <david@redhat.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>, Fuad Tabba <tabba@google.com>
Cc: 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
Subject: Re: [PATCH v14 02/21] KVM: Rename CONFIG_KVM_GENERIC_PRIVATE_MEM to CONFIG_KVM_GENERIC_GMEM_POPULATE
Date: Wed, 16 Jul 2025 14:14:17 +0200 [thread overview]
Message-ID: <f7a54cc4-1017-4e32-85b8-cf74237db935@redhat.com> (raw)
In-Reply-To: <fa1ccce7-40d3-45d2-9865-524f4b187963@intel.com>
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 <xiaoyao.li@intel.com> 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<xiaoyao.li@intel.com> 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?
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-07-16 12:14 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 9:33 [PATCH v14 00/21] KVM: Enable host userspace mapping for guest_memfd-backed memory for non-CoCo VMs Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 01/21] KVM: Rename CONFIG_KVM_PRIVATE_MEM to CONFIG_KVM_GMEM Fuad Tabba
2025-07-16 3:43 ` Xiaoyao Li
2025-07-15 9:33 ` [PATCH v14 02/21] KVM: Rename CONFIG_KVM_GENERIC_PRIVATE_MEM to CONFIG_KVM_GENERIC_GMEM_POPULATE Fuad Tabba
2025-07-16 4:08 ` Xiaoyao Li
2025-07-16 8:11 ` Fuad Tabba
2025-07-16 8:31 ` Xiaoyao Li
2025-07-16 10:25 ` David Hildenbrand
2025-07-16 11:02 ` Xiaoyao Li
2025-07-16 11:05 ` Fuad Tabba
2025-07-16 11:15 ` David Hildenbrand
2025-07-16 12:01 ` Xiaoyao Li
2025-07-16 12:13 ` Fuad Tabba
2025-07-16 12:14 ` David Hildenbrand [this message]
2025-07-16 12:24 ` Fuad Tabba
2025-07-16 12:39 ` Xiaoyao Li
2025-07-16 12:54 ` Fuad Tabba
2025-07-16 12:59 ` David Hildenbrand
2025-07-15 9:33 ` [PATCH v14 03/21] KVM: Introduce kvm_arch_supports_gmem() Fuad Tabba
2025-07-16 5:07 ` Xiaoyao Li
2025-07-15 9:33 ` [PATCH v14 04/21] KVM: x86: Introduce kvm->arch.supports_gmem Fuad Tabba
2025-07-16 5:18 ` Xiaoyao Li
2025-07-17 0:12 ` Ackerley Tng
2025-07-17 1:48 ` Xiaoyao Li
2025-07-17 8:49 ` Fuad Tabba
2025-07-17 9:00 ` Xiaoyao Li
2025-07-17 16:50 ` Ackerley Tng
2025-07-17 16:59 ` Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 05/21] KVM: Rename kvm_slot_can_be_private() to kvm_slot_has_gmem() Fuad Tabba
2025-07-16 5:19 ` Xiaoyao Li
2025-07-15 9:33 ` [PATCH v14 06/21] KVM: Fix comments that refer to slots_lock Fuad Tabba
2025-07-16 5:20 ` Xiaoyao Li
2025-07-15 9:33 ` [PATCH v14 07/21] KVM: Fix comment that refers to kvm uapi header path Fuad Tabba
2025-07-16 5:24 ` Xiaoyao Li
2025-07-15 9:33 ` [PATCH v14 08/21] KVM: guest_memfd: Allow host to map guest_memfd pages Fuad Tabba
2025-07-16 5:40 ` Xiaoyao Li
2025-07-16 8:15 ` Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 09/21] KVM: guest_memfd: Track guest_memfd mmap support in memslot Fuad Tabba
2025-07-16 6:10 ` Xiaoyao Li
2025-07-16 8:21 ` Fuad Tabba
2025-07-16 8:52 ` Xiaoyao Li
2025-07-16 10:31 ` David Hildenbrand
2025-07-16 10:59 ` Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 10/21] KVM: x86/mmu: Generalize private_max_mapping_level x86 op to max_mapping_level Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 11/21] KVM: x86/mmu: Allow NULL-able fault in kvm_max_private_mapping_level Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 12/21] KVM: x86/mmu: Consult guest_memfd when computing max_mapping_level Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 13/21] KVM: x86/mmu: Handle guest page faults for guest_memfd with shared memory Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 14/21] KVM: x86: Enable guest_memfd mmap for default VM type Fuad Tabba
2025-07-16 10:32 ` David Hildenbrand
2025-07-15 9:33 ` [PATCH v14 15/21] KVM: arm64: Refactor user_mem_abort() Fuad Tabba
2025-07-16 10:36 ` David Hildenbrand
2025-07-16 11:26 ` Fuad Tabba
2025-07-16 15:08 ` Marc Zyngier
2025-07-15 9:33 ` [PATCH v14 16/21] KVM: arm64: Handle guest_memfd-backed guest page faults Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 17/21] KVM: arm64: nv: Handle VNCR_EL2-triggered faults backed by guest_memfd Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 18/21] KVM: arm64: Enable host mapping of shared guest_memfd memory Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 19/21] KVM: Introduce the KVM capability KVM_CAP_GMEM_MMAP Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 20/21] KVM: selftests: Do not use hardcoded page sizes in guest_memfd test Fuad Tabba
2025-07-15 9:33 ` [PATCH v14 21/21] KVM: selftests: guest_memfd mmap() test when mmap is supported Fuad Tabba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7a54cc4-1017-4e32-85b8-cf74237db935@redhat.com \
--to=david@redhat.com \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=amoorthy@google.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=brauner@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=chao.p.peng@linux.intel.com \
--cc=chenhuacai@kernel.org \
--cc=dmatlack@google.com \
--cc=fvdl@google.com \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=ira.weiny@intel.com \
--cc=isaku.yamahata@gmail.com \
--cc=isaku.yamahata@intel.com \
--cc=james.morse@arm.com \
--cc=jarkko@kernel.org \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=jthoughton@google.com \
--cc=keirf@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=liam.merwick@oracle.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mail@maciej.szmigiero.name \
--cc=maz@kernel.org \
--cc=mic@digikod.net \
--cc=michael.roth@amd.com \
--cc=mpe@ellerman.id.au \
--cc=oliver.upton@linux.dev \
--cc=palmer@dabbelt.com \
--cc=pankaj.gupta@amd.com \
--cc=paul.walmsley@sifive.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qperret@google.com \
--cc=quic_cvanscha@quicinc.com \
--cc=quic_eberman@quicinc.com \
--cc=quic_mnalajal@quicinc.com \
--cc=quic_pderrin@quicinc.com \
--cc=quic_pheragu@quicinc.com \
--cc=quic_svaddagi@quicinc.com \
--cc=quic_tsoni@quicinc.com \
--cc=rientjes@google.com \
--cc=roypat@amazon.co.uk \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vannapurve@google.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=wei.w.wang@intel.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=xiaoyao.li@intel.com \
--cc=yilun.xu@intel.com \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.