Daniel P. Berrangé <berra...@redhat.com> writes:
> On Thu, Feb 11, 2021 at 09:30:53AM +0100, Vitaly Kuznetsov wrote:
>> Eduardo Habkost <ehabk...@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
