[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option
From: |
Eduardo Habkost |
Subject: |
Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option |
Date: |
Wed, 20 Jan 2021 14:55:15 -0500 |
On Wed, Jan 20, 2021 at 02:13:12PM +0100, Igor Mammedov wrote:
> On Fri, 15 Jan 2021 10:20:23 +0100
> Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>
> > Igor Mammedov <imammedo@redhat.com> writes:
> >
> > > On Thu, 7 Jan 2021 16:14:49 +0100
> > > Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
[...]
> > >> -No Hyper-V enlightenments are enabled by default by either KVM or QEMU.
> > >> In
> > >> -QEMU, individual enlightenments can be enabled through CPU flags, e.g:
> > >> +All currently supported Hyper-V enlightenments can be enabled by
> > >> specifying
> > >> +'hv-default=on' CPU flag:
> > >>
> > >> - qemu-system-x86_64 --enable-kvm --cpu
> > >> host,hv_relaxed,hv_vpindex,hv_time, ...
> > >> + qemu-system-x86_64 --enable-kvm --cpu host,hv-default ...
> > >> +
> > >> +Alternatively, it is possible to do fine-grained enablement through CPU
> > >> flags,
> > >> +e.g:
> > >> +
> > >> + qemu-system-x86_64 --enable-kvm --cpu
> > >> host,hv-relaxed,hv-vpindex,hv-time ...
> > >
> > > I'd put here not '...' but rather recommended list of flags, and update
> > > it every time when new feature added if necessary.
> > >
>
> 1)
>
> > This is an example of fine-grained enablement, there is no point to put
> > all the existing flags there (hv-default is the only recommended way
> > now, the rest is 'expert'/'debugging').
> so users are kept in dark what hv-default disables/enables (and it might
> depend
> on machine version on top that). Doesn't look like a good documentation to me
> (sure everyone can go and read source code for it and try to figure out how
> it's supposed to work)
Why is this a problem? This is not different from CPU feature
flags hidden by CPU model names. Or virtio feature bits hidden
by virtio devices and machine type compat code.
> > > (not to mention that if we had it to begin with, then new 'hv-default'
> > > won't
> > > be necessary, I still see it as functionality duplication but I will not
> > > oppose it)
> > >
> >
> > Unfortunately, upper layer tools don't read this doc and update
> > themselves to enable new features when they appear.
> rant: (just merge all libvirt into QEMU, and make VM configuration less
> low-level.
> why stop there, just merge with yet another upper layer, it would save us a
> lot
> on communication protocols and simplify VM creation even more,
> and no one will have to read docs and write anything new on top.)
> There should be limit somewhere, where QEMU job ends and others pile hw
> abstraction
> layers on top of it.
If there should be a limit somewhere, I'd say low level hyperv
flags are a very long way from crossing that limit. It is
completely reasonable to provide a higher level knob for them in
QEMU. Vitaly is trying to solve a real problem here, because the
existing solution is not working.
We only need to offer more complex and lower level interfaces if
we have to. I don't think we have real world examples where
libvirt or management software developers/users are asking for
low level hyperv feature flag knobs, do we?
>
> > Similarly, if when these tools use '-machine q35' they get all the new
> > features we add
> > automatically, right?
> it depends, in case of CPUs, new features usually 'off' by default
> for existing models. In case of bugs, features sometimes could be
> flipped and versioned machines were used to keep broken CPU models
> on old machine types.
>
>
[...]
--
Eduardo
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, (continued)
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Vitaly Kuznetsov, 2021/01/15
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Igor Mammedov, 2021/01/20
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Vitaly Kuznetsov, 2021/01/20
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Igor Mammedov, 2021/01/20
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Eduardo Habkost, 2021/01/20
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Igor Mammedov, 2021/01/21
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Igor Mammedov, 2021/01/21
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Vitaly Kuznetsov, 2021/01/21
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Igor Mammedov, 2021/01/21
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option, Vitaly Kuznetsov, 2021/01/21
- Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option,
Eduardo Habkost <=
[PATCH v3 19/19] qtest/hyperv: Introduce a simple hyper-v test, Vitaly Kuznetsov, 2021/01/07