On Thu, May 21, 2026, Fuad Tabba wrote: > Hi Ackerley, > > On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay > <[email protected]> wrote: > > > > From: Sean Christopherson <[email protected]> > > > > Make vm_memory_attributes a module parameter so that userspace can disable > > the use of memory attributes on the VM level. > > > > To avoid inconsistencies in the way memory attributes are tracked in KVM > > and guest_memfd, the vm_memory_attributes module_param is made > > read-only (0444). > > > > Make CONFIG_KVM_VM_MEMORY_ATTRIBUTES selectable, only for (CoCo) VM types > > that might use vm_memory_attributes. > > > > Signed-off-by: Sean Christopherson <[email protected]> > > Signed-off-by: Ackerley Tng <[email protected]> > > Config files always confuse me, but Sashiko might be onto something: > > https://sashiko.dev/#/patchset/20260507-gmem-inplace-conversion-v6-0-91ab5a8b19a4%40google.com?part=19
: Since this prompt does not have a default value, will it default to N : and silently drop KVM_VM_MEMORY_ATTRIBUTES during configuration updates : like make olddefconfig? : : Existing userspace VMMs that rely on the KVM_SET_MEMORY_ATTRIBUTES ioctl : for TDX or SEV VMs might fail to boot if the feature is unexpectedly : compiled out. Could a default y be used to preserve backwards : compatibility for existing configurations? > I think this partially goes back to commit 6, the one I flagged > yesterday. But also adding "default y" to KVM_VM_MEMORY_ATTRIBUTES? > The default value should at least fix this issue, but I'm not sure if > it would cause other problems... Hrm. As much as I want per-gmem attributes to be the default going forward, silently breaking existing setups isn't great. On the other hand, I'm *very* skeptical there are any SNP or TDX deployments using a distro kernel, so I'm still leaning towards forcing the issue and turning per-VM attributes off by default.
