summaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/kvm
diff options
context:
space:
mode:
authorVitaly Kuznetsov <vkuznets@redhat.com>2018-12-10 18:21:56 +0100
committerPaolo Bonzini <pbonzini@redhat.com>2018-12-14 17:59:54 +0100
commit2bc39970e9327ceb06cb210f86ba35f81d00e350 (patch)
tree151022f582e3d792292962cffd7ea2092e1f275f /tools/testing/selftests/kvm
parente2e871ab2f02dc9ca5f06065234475393dcec38b (diff)
downloadlinux-2bc39970e9327ceb06cb210f86ba35f81d00e350.tar.bz2
x86/kvm/hyper-v: Introduce KVM_GET_SUPPORTED_HV_CPUID
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@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/testing/selftests/kvm')
0 files changed, 0 insertions, 0 deletions