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)
