Sean Christopherson <[email protected]> writes: > 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.
Could you elaborate on the rationale for a wrapper? I don't really see a reason to encapsulate this boolean since this flag should be global to KVM, it toggles between tracking shared/private status at the VM or guest_memfd level. Since KVM is a module I guess it's already global just to KVM? On the naming, Sashiko did point out somewhere that gmem_in_place_conversion as a global might end up shadowing or being shadowed by something else. Prefixing kvm_ was one of Sashiko's suggestions too. I don't really have a strong opinion on this but I'd like to know what to put in v11. Will using module_param_named(gmem_in_place_conversion, kvm_gmem_in_place_conversion, bool, 0444); help? The module param doesn't have the kvm prefix but the variable does.
