On Wed, Jun 24, 2026 at 05:05:44PM -0700, Ackerley Tng wrote: > 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. Thanks for this background.
Some more context on why I'm asking: Currently, I'm testing TDX huge pages with the following two gmem components: 1. The gmem memory attribute in this gmem in-place conversion v8. 2. The gmem 2MB from buddy allocator. (for development/testing only). The gmem 2MB from buddy allocator allocates 2MB folios from buddy for private memory, while shared memory is allocated from a different backend. (To avoid fragmentation, only private mappings are split during private-to-shared conversions. In this approach, the 2MB folios are always retained in the gmem inode filemap cache without splitting.) Since shared memory is not allocated from gmem, there're no in-place conversions. The reason I'm using "gmem memory attribute" is that the per-VM attribute is being deprecated, as suggested by Sean [1]. Besides my current usage, there may be other scenarios where gmem memory attributes is preferred without allocating shared memory from gmem. (e.g., PAGE.ADD from a temp extra shared source memory). For such use cases, I'm concerns that the admins may find it confusing if they enable gmem_in_place_conversion but still observe extra memory consumptions for shared memory. [1] https://lore.kernel.org/kvm/[email protected]/ > 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...] > >>
