Re: [RFC PATCH v11 06/29] KVM: Introduce KVM_SET_USER_MEMORY_REGION2
From: Sean Christopherson <seanjc@google.com>
Date: 2023-07-29 00:03:41
Also in:
kvm, kvm-riscv, kvmarm, linux-arm-kernel, linux-fsdevel, linux-mips, linux-mm, linux-riscv, linux-security-module, lkml
On Fri, Jul 28, 2023, Quentin Perret wrote:
On Tuesday 18 Jul 2023 at 16:44:49 (-0700), Sean Christopherson wrote:quoted
--- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h@@ -95,6 +95,16 @@ struct kvm_userspace_memory_region { __u64 userspace_addr; /* start of the userspace allocated memory */ }; +/* for KVM_SET_USER_MEMORY_REGION2 */ +struct kvm_userspace_memory_region2 { + __u32 slot; + __u32 flags; + __u64 guest_phys_addr; + __u64 memory_size; + __u64 userspace_addr; + __u64 pad[16];Should we replace that pad[16] with: __u64 size; where 'size' is the size of the structure as seen by userspace? This is used in other UAPIs (see struct sched_attr for example) and is a bit more robust for future extensions (e.g. an 'old' kernel can correctly reject a newer version of the struct with additional fields it doesn't know about if that makes sense, etc).
"flags" serves that purpose, i.e. allows userspace to opt-in to having KVM actually consume what is currently just padding. The padding is there mainly to simplify kernel/KVM code, e.g. the number of bytes that KVM needs to copy in is static. But now that I think more on this, I don't know why we didn't just unconditionally bump the size of kvm_userspace_memory_region. We tried to play games with unions and overlays, but that was a mess[*]. KVM would need to do multiple uaccess reads, but that's not a big deal. Am I missing something, or did past us just get too clever and miss the obvious solution? [*] https://lkml.kernel.org/r/Y7xrtf9FCuYRYm1q%40google.com