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. 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.
