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: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>
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 09:30:53 +0100	[thread overview]
Message-ID: <87ft23m2f6.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20210210174652.GE1420762@habkost.net>

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.

-- 
Vitaly