On Tue, Mar 31, 2026, Michael Roth wrote: > On Thu, Mar 26, 2026 at 03:24:17PM -0700, Ackerley Tng wrote: > > Introduce a "version 2" of KVM_SET_MEMORY_ATTRIBUTES to support returning > > information back to userspace. > > Hi Ackerley, > > Not trying to bikeshed below, but I'm working on getting related QEMU > patches cleaned up to post soon and was working through some of the new > uAPI bits, and plumbing some of these capabilities in seems a little > awkward in a couple places so wondering if we should revisit how some of > this API is defined... > > > > > This new ioctl and structure will, in a later patch, be shared as a > > guest_memfd ioctl, where the padding in the new kvm_memory_attributes2 > > structure will be for writing the response from the guest_memfd ioctl to > > userspace. > > > > A new ioctl is necessary for these reasons: > > > > 1. KVM_SET_MEMORY_ATTRIBUTES is currently a write-only ioctl and does not > > allow userspace to read fields. There's nothing in code (yet?) that > > validates this, but using _IOWR for consistency would be prudent. > > > > 2. KVM_SET_MEMORY_ATTRIBUTES, when used as a guest_memfd ioctl, will need > > an additional field to provide userspace with more error details. > > > > Alternatively, a completely new ioctl could be defined, unrelated to > > KVM_SET_MEMORY_ATTRIBUTES, but using the same ioctl number and struct for > > the vm and guest_memfd ioctls streamlines the interface for userspace. In > > addition, any memory attributes, implemented on the vm or guest_memfd > > ioctl, can be easily shared with the other. > > > > Add KVM_CAP_MEMORY_ATTRIBUTES2 to indicate that struct > > kvm_memory_attributes2 exists and can be used either with > > KVM_SET_MEMORY_ATTRIBUTES2 via the vm or guest_memfd ioctl. > > The guest_memfd support for the KVM_SET_MEMORY_ATTRIBUTES2 ioctl isn't > added until patch #10, and to scan for it you sort of need to infer it > via KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES reporting non-zero (i.e. > KVM_MEMORY_ATTRIBUTE_PRIVATE), so it's confusing to state that > KVM_CAP_MEMORY_ATTRIBUTES2 means you can use the struct via a guest_memfd > ioctl. > > I think the above is trying to simply say that the corresponding struct > exists, and remain agnostic about how it can be used. But if that were > the case, there would be no way to know when KVM_SET_MEMORY_ATTRIBUTES2 is > available in the first place, so in the case of KVM ioctls at least, > KVM_CAP_MEMORY_ATTRIBUTES2 is advertising both the struct and the ioctl, > whereas for guest_memfd it's only advertising the struct and not saying > anything about whether a similar gmem ioctl is available to use it.
+1 to everything Mike said. > Instead, maybe they should both have the same semantics: > > KVM_CAP_MEMORY_ATTRIBUTES2: *SET_ATTRIBUTES* ioctl exists for KVM that > utilizes > struct kvm_memory_attributes2 > > KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES: *SET_ATTRIBUTES* ioctl exists for > guest_memfd that utilizes struct kvm_memory_attributes2 > > In which case you would leave out any mention of guest_memfd here as far as > the documentation does, and then in patch #10 you could modify it to be > something like: > > 4.145 KVM_SET_MEMORY_ATTRIBUTES2 > --------------------------------- > > -:Capability: KVM_CAP_MEMORY_ATTRIBUTES2 > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES2, > KVM_GUEST_MEMFD_CAP_MEMORY_ATTRIBUTES > -:Architectures: x86 > +:Architectures: all > -:Type: vm ioctl > +:Type: vm, guest_memfd ioctl > :Parameters: struct kvm_memory_attributes2 (in/out) > :Returns: 0 on success, <0 on error As discussed at PUCK, I think we should omit KVM_CAP_MEMORY_ATTRIBUTES2 and vm-scoped support entirely until it's needed (which may be never). > and *then* add in your mentions of how the usage/fields differ for > guest_memfd/KVM_GUEST_MEMFD_CAP_MEMORY_ATTRIBUTES case vs. KVM ioctls. > > This avoids needing to issue 2 checks for the guest_memfd variant vs. 1 > for KVM, but more importantly avoids subtle differences in how these > similarly-named capabilities are used/documented that might cause > unecessary confusion.
