On Wed, Jun 24, 2026, Ackerley Tng wrote:
> Yan Zhao <[email protected]> writes:
> > With gmem_in_place_conversion=true, userspace can create guest_memfd
> > without the
> > MMAP flag. In such cases, shared memory is allocated from different
> > backends.
> > This means this module parameter only enables per-gmem memory attribute and
> > does
> > not guarantee that gmem in-place conversion will actually occur.
KVM module params are pretty much always about what KVM supports, not what is
guaranteed to happen.
- enable_mmio_caching doesn't guarantee there will actually be MMIO SPTEs,
because maybe the guest never accesses emulated MMIO.
- enable_pmu doesn't guarantee VMs will get a PMU, because userspace may elect
not to advertise one.
- and so on and so forth...
Yes, there's a small mental jump to get from "KVM supports in-place conversion"
to "I need to set memory attributes on the guest_memfd instance, not the VM",
but I don't see that as a big hurdle, certainly not in the long term. And once
the VMM code is written, I really do think most people are going to care about
whether or not KVM supports in-place conversion, not where PRIVATE is tracked.
> > To avoid confusion, could we rename this module parameter to something more
> > accurate, such as gmem_memory_attribute?
>
> I asked Sean about this after getting some fixes off list. Sean said
> gmem_in_place_conversion is named for a host admin to use, and something
> like gmem_memory_attributes is too much implementation details for the
> admin.
>
> Sean, would you reconsider since Yan also asked? If the admin compiled
> the kernel knowing what CONFIG_KVM_VM_MEMORY_ATTRIBUTES means, then the
> admin would also be able to use a param like gmem_memory_attributes?
No, because it's not all memory attributes, it's very specifically the PRIVATE
attribute that will get moved to guest_memfd. I don't want to pick a name that
will become stale and confusing when RWX attributes come along. The RWX bits
will be per-VM, while PRIVATE will be per-guest_memfd.
