On Thu, Jun 25, 2026 at 11:20:30AM -0700, Ackerley Tng wrote: > Yan Zhao <[email protected]> writes: > > > 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]. > > > > v8 of conversions series changed that slightly, per-VM attributes is > going to stay around (because of work on RWX attributes, coming up) and > RWX will stay tracked at the VM level. > > For v8 and beyond, only tracking of private/shared in per-VM attributes > is being deprecated. > > By extension the entire thing about using guest_memfd for private memory > and a different backing memory for shared memory is being deprecated. Thanks for the info. I was actually referring to the per-VM shared/private attribute, which is being deprecated. Sean hoped TDX huge page would be the first mandated user of the per-gmem shared/private attribute.
> > Besides my current usage, > > I think you can set up guest_memfd+2M for private memory and shared > memory from some other source, and that's the deprecated usage pattern. Yes, though this is the deprecated usage pattern, gmem_in_place_conversion=true allows it. In fact, even without huge pages, v8 allows userspace to have shared memory allocated from other source when gmem_in_place_conversion=true. (My default testing of this series for the 4KB setting is with this configuration). > > 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). > > > > Is this TDH.MEM.PAGE.ADD, used indirectly from > tdx_gmem_post_populate()? This use case isn't blocked. Even if > gmem_in_place_conversion=true, you can still set src_address to > non-guest_memfd memory and load from anywhere you like. > > Please let me know if that is broken! I think I accidentally used that It's not broken. I tested it with my hacked-up QEMU. > setup in selftests and it worked. The selftests are now defaulting to > in-place conversion. > > > 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. > > > > Hmm but I guess if someone enables gmem_in_place_conversion but still > allocates from elsewhere, they'd have to figure it out? If gmem_in_place_conversion=true means gmem in place conversion is allowed (but not enforced), I agree. I'm wondering if we could rename it to "allow_gmem_in_place_conversion":) > > [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...] > >> >>
