[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 00/19] i386: KVM: expand Hyper-V features early and provid
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v4 00/19] i386: KVM: expand Hyper-V features early and provide simple 'hv-default=on' option |
Date: |
Wed, 10 Feb 2021 16:56:06 +0000 |
User-agent: |
Mutt/1.14.6 (2020-07-11) |
On Wed, Feb 10, 2021 at 05:40:12PM +0100, Vitaly Kuznetsov wrote:
> Changes since v3:
> - Make 'hv-default' override 'hv-*' options which were already set
> (e.g. 'hv-feature=on,hv-default' case) [Igor]. Make 'hv-passthrough'
> behave the same way.
> - Add "i386: be more picky about implicit 'hv-evmcs' enablement" patch to
> avoid
> enabling 'hv-evmcs' with hv-default/hv-passthrough when guest CPU lacks VMX.
> - Add "i386: support 'hv-passthrough,hv-feature=off' on the command line"
> patch
> to make 'hv-passthrough' semantics match the newly introduced 'hv-default'.
> - Add "i386: track explicit 'hv-*' features enablement/disablement" patch to
> support the above mentioned changes.
> - Expand qtest to check the above mentioned improvements.
>
> Original description:
>
> Upper layer tools like libvirt want to figure out which Hyper-V features are
> supported by the underlying stack (QEMU/KVM) but currently they are unable to
> do so. We have a nice 'hv_passthrough' CPU flag supported by QEMU but it has
> no effect on e.g. QMP's
>
> query-cpu-model-expansion type=full
> model={"name":"host","props":{"hv-passthrough":true}}
>
> command as we parse Hyper-V features after creating KVM vCPUs and not at
> feature expansion time. To support the use-case we first need to make
> KVM_GET_SUPPORTED_HV_CPUID ioctl a system-wide ioctl as the existing
> vCPU version can't be used that early. This is what KVM part does. With
> that done, we can make early Hyper-V feature expansion (this series).
>
> In addition, provide a simple 'hv-default' option which enables (and
> requires from KVM) all currently supported Hyper-V enlightenments.
> Unlike 'hv-passthrough' mode, this is going to be migratable.
How is it going to be migratable if the semantics vary depending on
the host kernel KVM reporting features, because different kernels
will expose different features ?
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- [PATCH v4 10/21] i386: move eVMCS enablement to hyperv_init_vcpu(), (continued)
- [PATCH v4 10/21] i386: move eVMCS enablement to hyperv_init_vcpu(), Vitaly Kuznetsov, 2021/02/10
- [PATCH v4 13/21] i386: prefer system KVM_GET_SUPPORTED_HV_CPUID ioctl over vCPU's one, Vitaly Kuznetsov, 2021/02/10
- [PATCH v4 16/21] i386: track explicit 'hv-*' features enablement/disablement, Vitaly Kuznetsov, 2021/02/10
- [PATCH v4 15/21] i386: expand Hyper-V features during CPU feature expansion time, Vitaly Kuznetsov, 2021/02/10
- [PATCH v4 14/21] i386: use global kvm_state in hyperv_enabled() check, Vitaly Kuznetsov, 2021/02/10
- [PATCH v4 21/21] qtest/hyperv: Introduce a simple hyper-v test, Vitaly Kuznetsov, 2021/02/10
- [PATCH v4 20/21] i386: provide simple 'hv-default=on' option, Vitaly Kuznetsov, 2021/02/10
- [PATCH v4 17/21] i386: support 'hv-passthrough, hv-feature=off' on the command line, Vitaly Kuznetsov, 2021/02/10
- [PATCH v4 18/21] i386: be more picky about implicit 'hv-evmcs' enablement, Vitaly Kuznetsov, 2021/02/10
- [PATCH v4 19/21] i386: introduce kvm_hv_evmcs_available(), Vitaly Kuznetsov, 2021/02/10
- Re: [PATCH v4 00/19] i386: KVM: expand Hyper-V features early and provide simple 'hv-default=on' option,
Daniel P . Berrangé <=