Sean Christopherson seanjc@google.com writes:
On Wed, Oct 22, 2025, Ackerley Tng wrote:
Ackerley Tng ackerleytng@google.com writes:
Found another issue with KVM_CAP_MEMORY_ATTRIBUTES2.
KVM_CAP_MEMORY_ATTRIBUTES2 was defined to do the same thing as KVM_CAP_MEMORY_ATTRIBUTES, but that's wrong since KVM_CAP_MEMORY_ATTRIBUTES2 should indicate the presence of KVM_SET_MEMORY_ATTRIBUTES2 and struct kvm_memory_attributes2.
No? If no attributes are supported, whether or not KVM_SET_MEMORY_ATTRIBUTES2 exists is largely irrelevant.
That's true.
We can even provide the same -ENOTTY errno by checking that _any_ attributes are supported, i.e. so that doing KVM_SET_MEMORY_ATTRIBUTES2 on KVM without any support whatsoever fails in the same way that KVM with code support but no attributes fails.
IIUC KVM_SET_MEMORY_ATTRIBUTES doesn't fail with -ENOTTY now when there are no valid attributes.
Even if there's no valid attributes (as in kvm_supported_mem_attributes() returns 0), it's possible to call KVM_SET_MEMORY_ATTRIBUTES with .attributes set to 0, which will be a no-op, but will return 0.
I think this is kind of correct behavior since .attributes = 0 is actually a valid expression for "I want this range to be shared", and for a VM that doesn't support private memory, it's a valid expression.
The other way that there are "no attributes" would be if there are no /VM/ attributes, in which case KVM_SET_MEMORY_ATTRIBUTES, sent to as a vm ioctl, will return -ENOTTY.
In other words, I don't see why it can't do both. Even if we can't massage the right errno, I would much rather KVM_SET_MEMORY_ATTRIBUTES2 enumerate the set of
Did you mean KVM_CAP_MEMORY_ATTRIBUTES2 in the line above?
supported attributes than simply '1'. E.g. we have no plans to support KVM_SET_MEMORY_ATTRIBUTES on guest_memfd, and so returning simply '1' creates an unwanted and unnecessary dependency.
Okay I'll switch this back to what it was.
@@ -1617,4 +1618,15 @@ struct kvm_pre_fault_memory { __u64 padding[5]; }; +/* Available with KVM_CAP_MEMORY_ATTRIBUTES2 */ +#define KVM_SET_MEMORY_ATTRIBUTES2 _IOWR(KVMIO, 0xd6, struct kvm_memory_attributes2)
Please use the same literal number, 0xd2, as
#define KVM_SET_MEMORY_ATTRIBUTES _IOW(KVMIO, 0xd2, struct kvm_memory_attributes)
The "final" ioctl number that userspace sees incorporates the directionality and the size of the struct, i.e. KVM_SET_MEMORY_ATTRIBUTES and KVM_SET_MEMORY_ATTRIBUTES2 are guaranteed to be distinct even if they both use 0xd2 as the "minor" number.
Will do.
+struct kvm_memory_attributes2 {
- __u64 address;
- __u64 size;
- __u64 attributes;
- __u64 flags;
- __u64 reserved[4];
Maybe be paranoid and reserve 12 u64s?
Will do.