Re: [PATCH v4 00/19] i386: KVM: expand Hyper-V features early and provide simple 'hv-default=on' option

[Vitaly Kuznetsov]

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Wed, Feb 10, 2021 at 04:56:06PM +0000, Daniel P. Berrangé wrote:
>> 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 ?
>
> "all currently supported" in this context means "all features
> supported when the machine type was added", not "all features
> supported by the host kernel".

Yes, exactly.

'hv-passthrough' enables 'everything supported by the host' and this is
not migratable.

'hv-default' requires a certain set of features (depending on the
machine type) so the VM won't start if the host lacks something.

-- 
Vitaly