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


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