Re: [PATCH v10 20/41] KVM: Let userspace disable per-VM mem attributes, enable per-gmem attributes

On Fri, Aug 14, 2026, Binbin Wu wrote:

On 8/8/2026 5:52 AM, Ackerley Tng via B4 Relay wrote:

quoted

From: Ackerley Tng <redacted>

Make gmem_in_place_conversion a module parameter so that userspace can
configure enable or disable the use of VM-level memory attributes. The
module parameter is only available if CONFIG_KVM_VM_MEMORY_ATTRIBUTES is
enabled.

To avoid inconsistencies in the way memory attributes are tracked in KVM
and guest_memfd, the vm_memory_attributes module_param is made

The description is stale, since there is no module_param called
vm_memory_attributes?

quoted

read-only (0444).

Since selecting CONFIG_KVM_VM_MEMORY_ATTRIBUTES disables in-place
conversion, 

"selecting CONFIG_KVM_VM_MEMORY_ATTRIBUTES" doesn't necessarily disable
in-place conversion, it also depends on the setting of
gmem_in_place_conversion.
To be accurate, maybe add "by default"?

+1.

Ackerley, please write changelogs in imperative mood, i.e. state things like this
as command, not as a passive description of what the code now does.  And I would
omit the blurb on changing the kvm_arch_has_private_mem() definition, for me that
falls into the category of giving a play-by-play explanation of the code change.
I.e. Let the diff speak for itself.

E.g.

  Allow the user to disable KVM_VM_MEMORY_ATTRIBUTES even when KVM supports
  PRIVATE and SHARED attributes, and expose gmem_in_place_conversion as a
  module parameter when per-VM attributes are supported.  I.e. let userspace
  enable in-place PRIVATE<=>SHARED conversion of guest_memfd pages.

  Provide both a Kconfig option and a (conditional) module param so that
  deployments that use a custom kernel can fully disable per-VM tracking,
  while not forcing distros to ship two separate kernels in order to provide
  backwards compatibility for downstream users.

  Don't allow running VMs with mixed tracking for a given instance of KVM,
  i.e. disallow toggling the module param after KVM is loaded, as the extra
  complexity needed to handle per-VM behavior far outweighs any potential
  benefit.  E.g. neither TDX nor SNP supports live migration, so in effect
  the requirement is that existing deployments that want to support both the
  old and the new models would need to tell their VMM which flavor of
  tracking to use.