| Message ID | 20181210172159.410-1-vkuznets@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86/kvm/hyper-v: Implement KVM_GET_SUPPORTED_HV_CPUID | expand |
On 10/12/18 18:21, Vitaly Kuznetsov wrote: > Changes since v1: > - Add Michael's R-b tags. > - Document KVM_GET_SUPPORTED_HV_CPUID and KVM_CAP_HYPERV_CPUID. > - Fix error handling in kvm_vcpu_ioctl_get_hv_cpuid(). > - Check for -E2BIG in the selftest. PATCH6 is added to support the change. > > As suggested by Paolo, introduce new KVM_GET_SUPPORTED_HV_CPUID returning > all Hyper-V CPUID feature leaves, this way we won't need to add a new > KVM_CAP_HYPERV_* for every new Hyper-V enlightenment we implement in > KVM. > > (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). > > This patch series also does some housekeeping work in hyperv-tlfs.h, adds a > simple selftest (that's how I actually checked that the newly added ioctl > works) and removes recently added KVM_CAP_HYPERV_STIMER_DIRECT before it's > too late. > > Vitaly Kuznetsov (7): > x86/hyper-v: Do some housekeeping in hyperv-tlfs.h > x86/hyper-v: Drop HV_X64_CONFIGURE_PROFILER definition > x86/kvm/hyper-v: Introduce nested_get_evmcs_version() helper > x86/kvm/hyper-v: Introduce KVM_GET_SUPPORTED_HV_CPUID > x86/kvm/hyper-v: Drop KVM_CAP_HYPERV_STIMER_DIRECT > KVM: selftests: implement an unchecked version of vcpu_ioctl() > KVM: selftests: Add hyperv_cpuid test > > Documentation/virtual/kvm/api.txt | 57 ++++++ > arch/x86/include/asm/hyperv-tlfs.h | 185 +++++++++--------- > arch/x86/include/asm/kvm_host.h | 1 + > arch/x86/kvm/hyperv.c | 125 +++++++++++- > arch/x86/kvm/hyperv.h | 2 + > arch/x86/kvm/svm.c | 7 + > arch/x86/kvm/vmx.c | 24 ++- > arch/x86/kvm/x86.c | 21 +- > include/uapi/linux/kvm.h | 5 +- > tools/testing/selftests/kvm/Makefile | 1 + > .../testing/selftests/kvm/include/kvm_util.h | 2 + > tools/testing/selftests/kvm/lib/kvm_util.c | 14 +- > .../selftests/kvm/x86_64/hyperv_cpuid.c | 157 +++++++++++++++ > 13 files changed, 493 insertions(+), 108 deletions(-) > create mode 100644 tools/testing/selftests/kvm/x86_64/hyperv_cpuid.c > Queued, thanks. I moved this above the direct EOI series so that KVM_CAP_HYPERV_STIMER_DIRECT need not exist at any point of the history. Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > > Queued, thanks. I moved this above the direct EOI series so that > KVM_CAP_HYPERV_STIMER_DIRECT need not exist at any point of the history. > Thanks! Just to make sure (and to conclude our discussion with Roman): with your Qemu maintainer hat on, do you agree with the design decision that KVM_GET_SUPPORTED_HV_CPUID's output value changes when KVM_CAP_HYPERV_ENLIGHTENED_VMCS gets enabled? This differs from KVM_GET_SUPPORTED_CPUID (where we always list all feature bits even if they require explicit enablement)?
On 17/12/18 11:30, Vitaly Kuznetsov wrote: >> Queued, thanks. I moved this above the direct EOI series so that >> KVM_CAP_HYPERV_STIMER_DIRECT need not exist at any point of the history. >> > Thanks! Just to make sure (and to conclude our discussion with Roman): > with your Qemu maintainer hat on, do you agree with the design decision > that KVM_GET_SUPPORTED_HV_CPUID's output value changes when > KVM_CAP_HYPERV_ENLIGHTENED_VMCS gets enabled? This differs from > KVM_GET_SUPPORTED_CPUID (where we always list all feature bits even if > they require explicit enablement)? It doesn't really matter, since the old capability cannot be removed. If you want to change it with a patch on top, that's also okay with me. Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > On 17/12/18 11:30, Vitaly Kuznetsov wrote: >>> Queued, thanks. I moved this above the direct EOI series so that >>> KVM_CAP_HYPERV_STIMER_DIRECT need not exist at any point of the history. >>> >> Thanks! Just to make sure (and to conclude our discussion with Roman): >> with your Qemu maintainer hat on, do you agree with the design decision >> that KVM_GET_SUPPORTED_HV_CPUID's output value changes when >> KVM_CAP_HYPERV_ENLIGHTENED_VMCS gets enabled? This differs from >> KVM_GET_SUPPORTED_CPUID (where we always list all feature bits even if >> they require explicit enablement)? > > It doesn't really matter, since the old capability cannot be removed. > If you want to change it with a patch on top, that's also okay with me. Ok, let's leave it as it is: maybe some other userspace (which doesn't use legacy capabilities) will be grateful :-)