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.
