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

On 8/10/26 17:01, Sean Christopherson wrote:
> On Mon, Aug 10, 2026, David Hildenbrand (Arm) wrote:
>> On 8/7/26 23:52, Ackerley Tng via B4 Relay wrote:
>>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>>> index 65fbce46b63f4..9477ecebbbced 100644
>>> --- a/include/linux/kvm_host.h
>>> +++ b/include/linux/kvm_host.h
>>> @@ -2580,6 +2580,8 @@ static inline bool kvm_vm_mem_is_private(struct kvm *kvm, gfn_t gfn)
>>>  #endif  /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>>>  
>>>  #ifdef kvm_arch_has_private_mem
>>> +extern bool gmem_in_place_conversion;
>>
>> Is there a "supports/has/enable" in there? And should we call it "kvm_gmem" for
>> completeness?
> 
> It's kinda stupid and definitely more than a bit inconsistent, but overall I think
> I actually like "gmem_in_place_conversion" the best.
> 
> gmem_has_in_place_conversion and gmem_supports_in_place_conversion are misleading
> because it's not just that guest_memfd has/supports in-place conversion, it's that
> that KVM is tracking PRIVATE in guest_memfd and so in-place conversion is the only
> option.
> 
> On the other hand, while gmem_in_place_conversion_enabled is better, it's not
> quite accurate either because userspace isn't strictly required to do in-place
> conversion.
> 
> As for a kvm_ prefix, IMO gmem_ is sufficient for a namespace, and not having kvm_
> is consistent with most module params in KVM.

Maybe we should have a helper function instead of accessing the module parameter
directly, then the gmem_in_place_conversion could just stay file-local and
kvm_gmem_in_place_conversion() would be used by other code that wants to obtain
the value.

Instead of the

#define mem_in_place_conversion false

We'd have

#define kvm_gmem_in_place_conversion()	false

just a thought ...

-- 
Cheers,

David