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

[Vitaly Kuznetsov]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Feb 11, 2021 at 09:30:53AM +0100, Vitaly Kuznetsov wrote:
>> 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.
>
> Ok, so I presume HV features will only be added to hv-default when we
> know they are available in the oldest kernel we are targetting ? Upsteam
> is more conservative in this respect than downstreams,  the latter can
> guarantee much more modern kernels.
>

Yes, it is kind of an open question when a feature gets 'promoted' to
'hv-default'. Currently, the latest feature we include is
'HYPERV_FEAT_STIMER_DIRECT' which dates back to Linux 5.0. It is also
possible to use something like

'hv-default,hv-stimer-direct=off,...'

when running on an older kernel (and this is still migratable).

-- 
Vitaly