Yan Zhao <[email protected]> writes: > > [...snip...] > >> >> #ifdef kvm_arch_has_private_mem >> -bool __ro_after_init gmem_in_place_conversion = false; >> +bool __ro_after_init gmem_in_place_conversion = >> !IS_ENABLED(CONFIG_KVM_VM_MEMORY_ATTRIBUTES); >> +module_param(gmem_in_place_conversion, bool, 0444); > > With gmem_in_place_conversion=true, userspace can create guest_memfd without > the > MMAP flag. In such cases, shared memory is allocated from different backends. > This means this module parameter only enables per-gmem memory attribute and > does > not guarantee that gmem in-place conversion will actually occur. > > To avoid confusion, could we rename this module parameter to something more > accurate, such as gmem_memory_attribute? >
I asked Sean about this after getting some fixes off list. Sean said gmem_in_place_conversion is named for a host admin to use, and something like gmem_memory_attributes is too much implementation details for the admin. Sean, would you reconsider since Yan also asked? If the admin compiled the kernel knowing what CONFIG_KVM_VM_MEMORY_ATTRIBUTES means, then the admin would also be able to use a param like gmem_memory_attributes? There's the additional benefit that the similar naming aids in understanding for both the admin and software engineers. Either way, in the next revision, I'll also add this documentation for this module_param: Setting the module parameter gmem_in_place_conversion to true will enable the KVM_SET_MEMORY_ATTRIBUTES2 guest_memfd ioctl and disables the KVM_SET_MEMORY_ATTRIBUTES VM ioctl. If gmem_in_place_conversion is true, the private/shared attribute will be tracked per-guest_memfd instead of per-VM. Let me know what y'all think of the wording! >> >> [...snip...] >>
