On Thu, Jun 25, 2026 at 07:36:28AM -0700, Sean Christopherson wrote: > On Thu, Jun 25, 2026, Yan Zhao wrote: > > 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" ? > > No, because turning on the param also disallows setting PRIVATE in the > VM-scoped > KVM_SET_MEMORY_ATTRIBUTES ioctl. > > > > 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, > > I fully expect that to be a transient state, and in all likelihood not > something > that is *ever* shipped in production. Landing TDX hugepages without > guest_memfd > hugepage support is all about avoiding unnecessary serialization of series and > features that aren't strictly dependent on each other. > > > > it should become more natural over time once gmem supports in-place > > > conversions for huge page. > > Yes, and I want to prioritize the steady state for end users, not the > in-progress > state for developers. Once all of this settles out, I fully expect the > majority > of deployments to only support in-place conversion, at which point the end > user > is only going to care whether or not in-place conversion is enabled in KVM, > not > the subtle detail that it's still possible to do out-of-place conversions (and > that will always hold true, it's not like VMA-based memslots are being > deprecated). > > > > 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. > > KVM can help with documentation, but beyond that, it's not KVM's problem to > solve. > If a VMM *and* platform owner chooses to deploy a setup that utilizes > out-of-place > conversions, then it's on the VMM and/or plaform owner to understand and > communicate > the implications to the end user. Thanks for all the explanations! Documentation that choosing a different source after enabling gmem_in_place_conversion is deprecated looks good to me. > And I'm not remotely convinced that prepending allow_ to the param will help > end users diagnose "unexpected" memory consumption, in quotes because anyone > that > is deploying a stack that utilizes out-of-place conversion absolutely needs to > understand and plan for the additional memory consumption. I.e. if the memory > consumption is "unexpected" to the end user, they likely have far bigger > problems. My first impression of gmem_in_place_conversion=true was that it enforces gmem in-place conversion. However, it actually only enforces per-gmem private/shared attribute. My worry was that people might think it's a kernel bug if userspace can still have shared memory from other sources after they configured gmem_in_place_conversion=true.
However, I have no strong opinion if you think gmem_in_place_conversion is good, and with the above documentation. :)
