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

From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v4 00/19] i386: KVM: expand Hyper-V features early and provide simple 'hv-default=on' option
Date: Thu, 11 Feb 2021 10:34:15 +0100	[thread overview]
Message-ID: <87czx7lzhk.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20210211091430.GB1302824@redhat.com>

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