Igor Mammedov wrote:
> my preferred approach is still -cpu hyperv=on, since it doesn't
> depend on order CLI is currently parsed (which is fragile thing),
> but rather on what user asked us to do with CPU.
I think I'm OK with this solution for the time being. When non-CPU
devices arrive and if we decide that it is a good idea to have them
enabled by default, we can make -machine hyperv=on option implying
'hv_default' CPU option. The real benefit I see from -cpu option is
simplification of debug configurations (to find out what would happen
if certain enlightenments are disabled) and making it possible to use
'hv_default' with older kernels lacking some enlightenments (by
disabling them). Not that this is impossible with -machine option, just
not very straitforward ('-cpu host,hv-default,hv-evmcs=off' vs '-machine
q35,hyperv=on -cpu host,hv-evmcs=off').
I'll send out v3 shortly and I'll include patches from "i386: KVM:
expand Hyper-V features early" which were waiting for Linux-5.11 merge
window.
Eduardo Habkost <ehabk...@redhat.com> writes:
>> > On Tue, 05 Jan 2021 17:31:43 +0100
>> > Vitaly Kuznetsov <vkuzn...@redhat.com> wrote:
>>
>> Every time I see a configuration with only a few 'hv_*' options I ask
>> 'why don't you enable the rest?' and I'm yet to receive an answer
>> different from 'hm, I don't know, I copied it from somewhere and it
>> worked'.
>>
>> Setting 'hv_*' options individually should be considered debug only.
>
> They can also be useful in production to work around
> unexpected issues (not just debugging).
>
Right, by 'debugging' I meant 'dealing with issues' :-)
> I don't think we should prevent other layers from controlling low
> level knobs. We just shouldn't make the low level knobs
> necessary for making the feature work.
Let me give an exaggerated example. Why do we have named cpu models
(e.g. 'Skylake')? We could've exposed basic CPU model and all the knobs
to upper layers of the stack to deal with. I don't even want to imagine
the chaos this would've created. Low level knobs are necessary when
issues arise (e.g. it's easy to ask 'could you please try "-cpu
Skylake,-vmx" and see what happens?') but mandating that upper layers
(btw, all of them -- we don't have 'one libvirt to rule them all') have
to set them is non-practical IMO.
--
Vitaly
