Messages in this thread | | | From | Vitaly Kuznetsov <> | Subject | Re: [PATCH v2 3/4] x86/kvm/hyper-v: direct mode for synthetic timers | Date | Mon, 26 Nov 2018 18:14:49 +0100 |
| |
Paolo Bonzini <pbonzini@redhat.com> writes:
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index 2b7a652c9fa4..b8da14cee8e5 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -975,6 +975,7 @@ struct kvm_ppc_resize_hpt { >> #define KVM_CAP_HYPERV_ENLIGHTENED_VMCS 163 >> #define KVM_CAP_EXCEPTION_PAYLOAD 164 >> #define KVM_CAP_ARM_VM_IPA_SIZE 165 >> +#define KVM_CAP_HYPERV_STIMER_DIRECT 166 > > I wonder if all these capabilities shouldn't be replaced by a single > KVM_GET_HYPERV_SUPPORTED_CPUID ioctl, or something like that. If you > can do it for 4.21, before this one cap is crystallized into userspace > API, that would be great. :)
Oh, so the suggestion is to get all these features in CPUID format (leafs 0x40000001-0x4000000A at this moment - as Hyper-V encodes them) and let userspace parse them. Could work. Will take a look.
Alternatively, we can go with 'something like that' and add a generalized KVM_GET_HYPERV_SUPPORTED_CAPS ioctl (returning somehthing like u64 feature, u64 parameter pair). Doing that, however, wouldn't relieve us from adding a new KVM_CAP_HYPERV_* constant for every new feature.
-- Vitaly
| |