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 <[email protected]> writes:
> 
> > On 8/10/2026 11:01 PM, Sean Christopherson wrote:
> >>> 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)