Re: [PATCH v10 07/41] KVM: guest_memfd: Stub in ability to enable in-place shared<=>private conversion
From: Xiaoyao Li
Date: Mon Aug 24 2026 - 23:46:39 EST
On 8/24/2026 10:45 PM, Ackerley Tng wrote:
Xiaoyao Li <xiaoyao.li@xxxxxxxxx> writes:
On 8/8/2026 5:52 AM, Ackerley Tng via B4 Relay wrote:
From: Sean Christopherson <seanjc@xxxxxxxxxx>
Stub in global variable to enable in-place guest_memfd private<=>shared
memory conversion, which will eventually be exposed to userspace via a
module param, and wire up the __kvm_mem_is_private() static call to the
guest_memfd version when in-place conversion is enabled, i.e. when gmem is
the sole authority on private vs. shared memory.
I find this patch changes the default memory type for a @gfn.
- When memory attribute is tracked per-VM, the default memory type is
always shared.
- when gmem_in_place_conversion is true,
- if the @gfn has no memslot, or the memslot where the @gfn locates
doesn't have gmem bound, the default memory type is shared,
- otherwise, the default memory type is determined by the
GUEST_MEMFD_FLAG_INIT_SHARED flag.
I think we should document this change.
In a way it's not really a "change" since gmem_in_place_conversion is
set up as false in this patch.
I agree. It is not this patch making the change but the patch allows gmem_in_place_conversion to be true.
When it is enabled in a later patch, another way to see it is that the
default remains "shared unless defined as private".
Before:
+ no memslot, or memslot not bound to gmem => shared
+ memory is shared unless VM ioctl used to make gfn private.
After:
+ no memslot, or memslot not bound to gmem => still shared
+ otherwise, ask gmem about status, which I think is already captured in
the module param concept.
+ The very usage of gmem (without INIT_SHARED) is defining memory as
private, I think that is already documented elsewhere when
INIT_SHARED was introduced, that now the default is private.
So in summary, I feel that this has already been documented in various
places. I'll also add the following in v11's "KVM: Let userspace disable
per-VM mem attributes, enable per-gmem attributes", in
Documentation/admin-guide/kernel-parameters.txt:
kvm.gmem_in_place_conversion=
[KVM] Controls whether KVM enables in-place conversion
support for guest_memfd and tracks the private/shared
state of memory per guest_memfd instead of per VM.
If enabled (the default), KVM enables the
I think the default is disabled?
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.
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.