On Thu, Jun 25, 2026 at 09:51:01AM +0800, Yan Zhao wrote: > On Wed, Jun 24, 2026 at 05:41:58PM -0700, Sean Christopherson wrote: > > On Wed, Jun 24, 2026, Ackerley Tng wrote: > > > Yan Zhao <[email protected]> writes: > > > > 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. > > > > KVM module params are pretty much always about what KVM supports, not what > > is > > guaranteed to happen. > > > > - enable_mmio_caching doesn't guarantee there will actually be MMIO SPTEs, > > because maybe the guest never accesses emulated MMIO. > > - enable_pmu doesn't guarantee VMs will get a PMU, because userspace may > > elect > > not to advertise one. > > - and so on and so forth... > > > > Yes, there's a small mental jump to get from "KVM supports in-place > > conversion" > > to "I need to set memory attributes on the guest_memfd instance, not the > > VM", > > but I don't see that as a big hurdle, certainly not in the long term. And > > once > > the VMM code is written, I really do think most people are going to care > > about > > whether or not KVM supports in-place conversion, not where PRIVATE is > > tracked. > Sorry, I just saw this mail after posting my reply in [1]. > > I'm ok with gmem_in_place_conversion=true just means KVM supports in-place > conversion, while we can still create VMs with shared memory not from gmem. Or what about "allow_gmem_in_place_conversion" ?
> Though it still feels a bit odd to require TDX huge pages to depend on > gmem_in_place_conversion=true when shared memory is not currently allocated > from > gmem, it should become more natural over time once gmem supports in-place > conversions for huge page. > > [1] https://lore.kernel.org/all/[email protected] > > > > > > 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? > > > > No, because it's not all memory attributes, it's very specifically the > > PRIVATE > > attribute that will get moved to guest_memfd. I don't want to pick a name > > that > > will become stale and confusing when RWX attributes come along. The RWX > > bits > > will be per-VM, while PRIVATE will be per-guest_memfd.
