Re: [PATCH v8 24/46] KVM: guest_memfd: Make in-place conversion the default\

[Yan Zhao]

On Fri, Jun 26, 2026 at 12:06:40PM -0700, Sean Christopherson wrote:
> 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.
Ok.