Re: [PATCH v2 01/13] KVM: Rework KVM_CAP_GUEST_MEMFD_MMAP into KVM_CAP_GUEST_MEMFD_FLAGS

[Ackerley Tng <ackerleytng@google.com>]

Sean Christopherson <seanjc@google.com> writes:

> Rework the not-yet-released KVM_CAP_GUEST_MEMFD_MMAP into a more generic
> KVM_CAP_GUEST_MEMFD_FLAGS capability so that adding new flags doesn't
> require a new capability, and so that developers aren't tempted to bundle
> multiple flags into a single capability.
>
> Note, kvm_vm_ioctl_check_extension_generic() can only return a 32-bit
> value, but that limitation can be easily circumvented by adding e.g.
> KVM_CAP_GUEST_MEMFD_FLAGS2 in the unlikely event guest_memfd supports more
> than 32 flags.
>

I know you suggested that guest_memfd's HugeTLB sizes shouldn't be
squashed into the flags. Just using that as an example, would those
kinds of flags (since they're using the upper bits, above the lower 32
bits) be awkward to represent in this new model?

In this model, conditionally valid flags are always set, but userspace
won't be able to do a flags check against the returned 32-bit value. Or
do you think when this issue comes up, we'd put the flags in the upper
bits in KVM_CAP_GUEST_MEMFD_FLAGS2 and userspace would then check
against the OR-ed set of flags instead?

Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Ackerley Tng <ackerleytng@google.com>

> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>  Documentation/virt/kvm/api.rst                 | 10 +++++++---
>  include/uapi/linux/kvm.h                       |  2 +-
>  tools/testing/selftests/kvm/guest_memfd_test.c | 13 ++++++-------
>  virt/kvm/kvm_main.c                            |  7 +++++--
>  4 files changed, 19 insertions(+), 13 deletions(-)
>
> 
> [...snip...]
>