On Fri, Jun 26, 2026, Yan Zhao wrote: > On Thu, Jun 25, 2026 at 07:36:28AM -0700, Sean Christopherson wrote: > > On Thu, Jun 25, 2026, Yan Zhao wrote: > > 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.
Ah, I see where you're coming from. FWIW, truly enforcing in-place conversion is flat out impossible. E.g. userspace can simply replace the memslot, at which point the memory effectively reverts to shared. > However, I have no strong opinion if you think gmem_in_place_conversion is > good, > and with the above documentation. :) Ya, I think this largely a documentation problem. I agree that a param name like gmem_private_memory_attributes would be more precise, but I think it'd be far less informative for the vast majority of users that only care whether or not KVM can do in-place conversion, and don't care about how that is done.
