Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> writes: > With every new Hyper-V Enlightenment we implement we're forced to add a > KVM_CAP_HYPERV_* capability. While this approach works it is fairly > inconvenient: the majority of the enlightenments we do have corresponding > CPUID feature bit(s) and userspace has to know this anyways to be able to > expose the feature to the guest. > > Add KVM_GET_SUPPORTED_HV_CPUID ioctl (backed by KVM_CAP_HYPERV_CPUID, "one > cap to rule them all!") returning all Hyper-V CPUID feature leaves. > > Using the existing KVM_GET_SUPPORTED_CPUID doesn't seem to be possible: > Hyper-V CPUID feature leaves intersect with KVM's (e.g. 0x40000000, > 0x40000001) and we would probably confuse userspace in case we decide to > return these twice. > > KVM_CAP_HYPERV_CPUID's number is interim: we're intended to drop > KVM_CAP_HYPERV_STIMER_DIRECT and use its number instead. > > Suggested-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> > Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> > --- > arch/x86/kvm/hyperv.c | 127 +++++++++++++++++++++++++++++++++++++++ > arch/x86/kvm/hyperv.h | 2 + > arch/x86/kvm/x86.c | 20 ++++++ > include/uapi/linux/kvm.h | 4 ++ Well, this is a bit embarrassing but apparently I forgot to document both KVM_GET_SUPPORTED_HV_CPUID and KVM_CAP_HYPERV_CPUID (I, as usual was postponing documentation writing for as long as I could - and then just sent this out). Stay tuned, v2 is coming. -- Vitaly
