On Wed, Jan 20, 2021 at 02:13:12PM +0100, Igor Mammedov wrote: > On Fri, 15 Jan 2021 10:20:23 +0100 > Vitaly Kuznetsov <vkuzn...@redhat.com> wrote: > > > Igor Mammedov <imamm...@redhat.com> writes: > > > > > On Thu, 7 Jan 2021 16:14:49 +0100 > > > Vitaly Kuznetsov <vkuzn...@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
