Re: [PATCH v10 07/41] KVM: guest_memfd: Stub in ability to enable in-place shared<=>private conversion

On Thu, Aug 13, 2026, Ackerley Tng wrote:

Xiaoyao Li [off-list ref] writes:

quoted

On 8/10/2026 11:01 PM, Sean Christopherson wrote:

quoted

quoted

As mentioned in v9, the name is confusing.

	kvm_gmem_mem_is_private

?

Ya, +1 to kvm_gmem_mem_is_private.

So kvm_gmem_mem_is_private() calls kvm_gmem_is_private_mem()
internallly. Ummmm.

How about

  kvm_gmem_mem_is_private(kvm, gfn)
  __gmem_mem_is_private(inode, index)  <== this is a static function
                                           anyway, though it calls
                                           kvm_gmem_get_attributes(inode, entry)

Hmm, what if we do:

	kvm_gmem_is_private_gfn(kvm, gfn)
	kvm_gmem_is_private_mem(inode, index)
	
And then to be consistent with the non-gmem code, slot in the rename you suggest
below:

  KVM: Rename memory attribute APIs to prepare for in-place gmem conversion
  <rename kvm_mem_is_private() => kvm_is_private_gfn()>
  KVM: Provide generic interface for checking memory private/shared status

I would also be a-ok with:

	kvm_gmem_is_private_mem(kvm, gfn)
	__kvm_gmem_is_private_mem(inode, index);

along with a kvm_mem_is_private() => kvm_is_private_mem() rename, though the more
I look at this, the more I prefer scoping the external API to a gfn.  Especially
for the guest_memfd code, where KVM needs to query shared vs. private without a
gfn.

I don't love kvm_gmem_mem_is_private(), it looks like a typo (though as above, I
do like it more than kvm_gmem_is_private()).

or

  kvm_gmem_gfn_is_private(kvm, gfn)
  kvm_gmem_is_private_mem(inode, index)

  (rename the vm stuff with the suffix gfn_is_private())

or (current, it is actually weird)

  kvm_gmem_mem_is_private(kvm, gfn)
  kvm_gmem_is_private_mem(inode, index)

or

  kvm_gmem_mem_is_private(kvm, gfn)
  kvm_gmem_index_is_private(inode, index)