Paolo Bonzini <pbonzini@xxxxxxxxxx> 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
