[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] qemu: Don't try to parse -help for new QEMU



On Wed, Nov 12, 2014 at 18:37:15 +0100, Peter Krempa wrote:
> On 11/12/14 17:09, Jiri Denemark wrote:
> > Since QEMU 1.2.0, we switched to QMP probing instead of parsing -help
> > (and other commands, such as -cpu ?) output. However, if QMP probing
> > failed, we still tried starting QEMU with various options and parsing
> > the output, which was guaranteed to fail because the output changed.
> > Let's just refuse parsing -help for QEMU >= 1.2.0.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1160318
> > Signed-off-by: Jiri Denemark <jdenemar redhat com>
> > ---
> >  src/qemu/qemu_capabilities.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> > index 74a3b24..bef96d5 100644
> > --- a/src/qemu/qemu_capabilities.c
> > +++ b/src/qemu/qemu_capabilities.c
> > @@ -1384,6 +1384,16 @@ int virQEMUCapsParseHelpStr(const char *qemu,
> >  
> >      *version = (major * 1000 * 1000) + (minor * 1000) + micro;
> >  
> > +    /* Refuse to parse -help output for QEMU releases >= 1.2.0 that should be
> > +     * using QMP probing.
> > +     */
> > +    if (*version > 1002000) {
> > +        virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> > +                       _("QEMU %u.%u.%u is too new for help parsing"),
> > +                       major, minor, micro);
> > +        goto cleanup;
> > +    }
> > +
> >      if (virQEMUCapsComputeCmdFlags(help, *version, *is_kvm, *kvm_version,
> >                                     qemuCaps, check_yajl) < 0)
> >          goto cleanup;
> > 
> 
> ACK, although I think that one of the steps that lead to fixing the
> issue for the reporter was to purge the caps cache. As I've heard/seen
> that happening we might want to check the code that checks the validity
> of the cache.

Right, but in this case it's a bit more complicated because the thing
that changed and thus should have triggered caps regeneration was HW
configration. In other words, HW virt was turned on. Not something we
could easily consider when checking cache validity.

Jirka


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]