[libvirt] [PATCH v2 02/17] qemu: remove all support for kQEMU

[Jiri Denemark]

On Tue, Nov 10, 2015 at 12:06:21 -0700, Eric Blake wrote:
> On 11/09/2015 09:24 AM, Daniel P. Berrange wrote:
> > The kQEMU accelerator was deleted in QEMU 0.12, so we no
> > longer need to support it in the QEMU driver.
> > 
> > Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
> > ---
> >  src/qemu/qemu_capabilities.c | 18 ------------------
> >  src/qemu/qemu_capabilities.h | 19 ++++++++++++++++---
> >  src/qemu/qemu_command.c      | 23 ++---------------------
> >  3 files changed, 18 insertions(+), 42 deletions(-)
> > 
> 
> > @@ -1103,10 +1089,6 @@ virQEMUCapsComputeCmdFlags(const char *help,
> >      const char *p;
> >      const char *fsdev, *netdev;
> >  
> > -    if (strstr(help, "-no-kqemu"))
> > -        virQEMUCapsSet(qemuCaps, QEMU_CAPS_KQEMU);
> > -    if (strstr(help, "-enable-kqemu"))
> > -        virQEMUCapsSet(qemuCaps, QEMU_CAPS_ENABLE_KQEMU);
> >      if (strstr(help, "-no-kvm"))
> >          virQEMUCapsSet(qemuCaps, QEMU_CAPS_KVM);
> >      if (strstr(help, "-enable-kvm"))
> 
> Question for the entire series: anywhere that libvirt 1.2.21 has a
> capability set, and a running domain, the XML for that domain tracks the
> capability name; if we then upgrade to libvirt 1.3.0 that does not even
> track the capability, won't trying to parse the XML will throw up its
> hands about an unknown capability?  Do we need to revisit how we are
> handling deletion of capabilities to make sure it does not interfere
> with libvirtd upgrades while managing a running domain?

Even libvirt 1.3.0 still knows about the capabilities, they are prefixed
with X_ in the enum and the corresponding strings are still in place,
and they will be recognized when parsing capabilities from both cache
and status XMLs. We just never check for such capabilities anywhere in
the code. That said, I think we're fine with upgrades.

Jirka