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