On Wed, Aug 12, 2026, David Hildenbrand (Arm) wrote: > 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 ...
FWIW, I'd rather prefix kvm_ than add a wrapper to get a boolean.
