On Wed, Sep 02, 2026, Binbin Wu wrote: > On 9/2/2026 2:26 AM, Sean Christopherson wrote: > > On Tue, Sep 01, 2026, Fuad Tabba wrote: > >> Hi Sean, Ackerley, > >> > >> On Mon, 31 Aug 2026 at 01:25, Ackerley Tng via B4 Relay > >> <[email protected]> wrote: > >> ... > >>> + 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, KVM enables the > >>> 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. 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). > >> > >> The parameter is only settable when CONFIG_KVM_VM_MEMORY_ATTRIBUTES=y, and > >> in that config gmem_in_place_conversion initialises to > >> !IS_ENABLED(CONFIG_KVM_VM_MEMORY_ATTRIBUTES), i.e. N, not Y. Is the doc > >> line > >> wrong, or is N-by-default not what was intended here? > > > > The doc is wrong. The intent is to maintain backwards compatibility with > > existing > > deployments if KVM_VM_MEMORY_ATTRIBUTES=y. > > > > Will it result in the situation that kernel builds with > CONFIG_KVM_VM_MEMORY_ATTRIBUTES > enabled by default for backwards compatibility, which requires users to > explicitly enable > gmem_in_place_conversion by the kernel option? Then it effectively disables > gmem_in_place_conversion by default.
Yes. My intent/expectation is that the only reason to build with CONFIG_KVM_VM_MEMORY_ATTRIBUTES=y is for backwards compatibility, and so it makes sense to have the existing behavior be the default. If a deployment only wants the new behavior, then it can simply build with CONFIG_KVM_VM_MEMORY_ATTRIBUTES=n. Folks that want only the new behavior but are using a distro/pre-built kernel will need to manually enable in-place conversion, but that's not too onerous, and it's simply not feasible to provide defaults that work for every possible scenario. > But I guess it's OK for CSPs since they know what they want. Yep.
