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

[Daniel P . Berrangé]

On Thu, Feb 11, 2021 at 10:34:15AM +0100, Vitaly Kuznetsov wrote:
> 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

Upstream we have a clear set of targetted OS platforms:

  https://qemu.readthedocs.io/en/latest/system/build-platforms.html

This will inform what our minimum possible kernel version will be,
which should influence when we can promote something.

Downstream's of course have their own min kernel model, so they can
do things differently if they have their own machine types.

> 'hv-default,hv-stimer-direct=off,...'
> 
> when running on an older kernel (and this is still migratable).

At that point the mgmt app needs to know exactly what features the
host supports, and if they know that, there's no real need to use
hv-default in the first place. IOW, I think we need to strive to
ensure "hv-default" is always usable on supported platforms without
needing to know about turning off things.


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 :|