Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types

[Igor Mammedov]

On Tue, 05 Jan 2021 17:31:43 +0100
Vitaly Kuznetsov <vkuznets@redhat.com> wrote:

> Igor Mammedov <imammedo@redhat.com> writes:
> 
> > On Tue, 05 Jan 2021 12:50:05 +0100
> >
> > I think there is a misunderstanding, idea was:
> >
> > cpu_initfn() {
> >     //current set
> >     cpu->default_hyperv_cpu_features = ACD
> > }
> >
> > compat_props_5.1 {
> >    cpu.default_hyperv_cpu_features = AB
> > }
> >
> > compat_props_5.2 {
> >    cpu.default_hyperv_cpu_features = ABC
> > }
> >  
> 
> ...
> 
> > I was talking about CPU features/properties only, it doesn't apply to other 
> > devices.
> > It makes sense for machine to have a knob to create onboard hyperv specific
> > devices if there is any (do we have any?).
> >
> > If there aren't any currently, I wouldn't bother with machine knob
> > and just use -cpu foo,hv_default=on or -device cpu,hv_default=on
> > like any other cpu feature.
> >  
> 
> We don't currently have any devices which are not 'CPU features' (in
> QEMU terminology), however, we already have Vmbus and I can easily
> imagine us implementing e.g. hartbeat/kvp/vss/... devices on top. We
> *may* want to enable these 'automatically' and that's what make
> '-machine' option preferable. It is, however, not a *must* right now and
> we can indeed wait until these devices appear and be happy with
> 'hv_default' -cpu option for now. We will, however, need to teach upper
> layers about the change when/if it happens.

which makes me think we are trying to bite something that we shouldn't.
Do we really need this patch (QEMU knob) to magically enable subset of
features and/or devices for a specific OS flavor?

It's job of upper layers to abstract low level QEMU details in to coarse
grained knobs (libvirt/virt-install/virt-manager/...).
For example virt-install may know that it installing a specific Windows
version, and can build a tailored for that OS configuration including
needed hyperv CPU features and hyperv specific devices.
(if I'm not mistaken libosinfo is used to get metadata for preferred
configuration, so perhaps this should become a patch for that library
and its direct users).

What we actually lack is a documentation for preferred configuration
in docs/hyperv.txt, currently it just enumerates possible features.
We can just document a recommended 'best practices' there without
putting it in QEMU code and let upper layers to do their job in
the stack.