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: ^^^^^
