Re: [PATCH v10 07/41] KVM: guest_memfd: Stub in ability to enable in-place shared<=>private conversion

On Mon, Aug 24, 2026, Ackerley Tng wrote:
> Xiaoyao Li <[email protected]> writes:
> >> 			KVM_SET_MEMORY_ATTRIBUTES2 ioctl on guest_memfd file
> >> 			descriptors and disables the legacy VM-scoped
> >> 			KVM_SET_MEMORY_ATTRIBUTES ioctl for private memory state
> >> 			tracking. Only the KVM_MEMORY_ATTRIBUTE_PRIVATE
> >> 			attribute moves to per-guest_memfd tracking; other
> >> 			attributes remain per-VM.
> >>
> >> 			This parameter toggles KVM's in-place conversion
> >> 			capability support.
> >
> > I start to think that the term "in-place conversion" seems to read
> > inaccurate. I think it is describing the shared/private conversion of a
> > gfn, and in-place means when a gfn is converted between shared/private,
> > the backend comes from the same gmem page, thus in-place. But KVM
> > doesn't enforce the "in-place".
> >
> > If "in-place conversion" describes the shared/private conversion of a
> > gmem page, then "in-place" is redundant because the conversion a
> > specific gmem page is always in-place.
> 
> Hmm, a few people have raised something related to this
> gmem_in_place_conversion module param's naming: Xiaoyao, Yan, David, and
> Sean's response is generally that it is confusing, but can't find a
> better way out. The main consideration around module param naming is
> that it should be named for the benefit of the admin. We want some name
> that admins can understand at a high level (for some definition of "high
> level") what this does.

Executive decision: use gmem_in_place_conversion.  I hear (and largely agree with)
the complaints that it's imperfect, but I don't think it's feasible to find a name
that can perfectly describe the nuances while still being somewhat succint and
intuitive.  I.e. gmem_in_place_conversion isn't perfect, but everything else I've
seen is much worse.

I'll make sure to call out that gmem_in_place_conversion is imperfect in the pull
request, to give Paolo a chance to veto my executive decision.

> Do you have a proposal to resolve your concern, considering naming,
> documentation, comments, code, etc?
> 
> >>                       Whether a VMM uses separate backends
> >> 			or out-of-place memory management is determined by
> >> 			userspace VMM design.
> >>
> >> 			Note, this parameter is only available when
> >> 			CONFIG_KVM_VM_MEMORY_ATTRIBUTES=y. When
> >> 			CONFIG_KVM_VM_MEMORY_ATTRIBUTES is not set, in-place
> >> 			conversion is unconditionally enabled.
> >>
> >> 			Default is Y (on).
> >
> > I'm looking at the doc of KVM_SET_USER_MEMORY_REGION2, which reads
> >
> > # When mapping a gfn into the guest, KVM selects shared vs. private, i.e consumes
> > # userspace_addr vs. guest_memfd, based on the gfn's KVM_MEMORY_ATTRIBUTE_PRIVATE
> > # state.  At VM creation time, all memory is shared, i.e. the PRIVATE attribute
> > # is '0' for all gfns.  Userspace can control whether memory is shared/private by
> > # toggling KVM_MEMORY_ATTRIBUTE_PRIVATE via KVM_SET_MEMORY_ATTRIBUTES as needed.
> 
> I'm not sure how this snippet from the documentation connects with what
> you'd like changed.

It's flat out wrong once in-place conversion lands, because it assumes PRIVATE
is tracked per-VM.  Something like this?

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 4eb7e75a7473..c9769e5e7329 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6383,9 +6383,12 @@ on-demand.
 
 When mapping a gfn into the guest, KVM selects shared vs. private, i.e consumes
 userspace_addr vs. guest_memfd, based on the gfn's KVM_MEMORY_ATTRIBUTE_PRIVATE
-state.  At VM creation time, all memory is shared, i.e. the PRIVATE attribute
-is '0' for all gfns.  Userspace can control whether memory is shared/private by
+state.  If in-place conversion is disabled, i.e. PRIVATE is tracked per-VM,
+then at VM creation time, all memory is shared, i.e. the PRIVATE attribute is
+'0' for all gfns.  Userspace can control whether memory is shared/private by
 toggling KVM_MEMORY_ATTRIBUTE_PRIVATE via KVM_SET_MEMORY_ATTRIBUTES as needed.
+If in-place conversion is enabled, then the starting PRIVATE vs. SHARED state
+of a gfn is determined by the relevant guest_memfd instance.
 
 S390:
 ^^^^^