Re: [Qemu-devel] qmp problems with --enable-kvm

[Luiz Capitulino <lcapitulino@redhat.com>]

On Thu, 22 Nov 2012 14:33:24 -0200
Luiz Capitulino <lcapitulino@redhat.com> wrote:

> On Thu, 22 Nov 2012 14:24:14 -0200
> Luiz Capitulino <lcapitulino@redhat.com> wrote:
> 
> > > It seems like mon->mc->command_mode is set wrong, looking at
> > > qmp_cmd_mode and its callers.  Luiz may have more ideas.
> > 
> > Checking. What I've just found is that qmp_capabilites will fail if the
> > VM is stopped (!?).
> 
> It's a regression somewhere. I doubt it's qmp, but could be.
> 
> Here are the symptoms, Doc:
> 
>  1. Start qemu and stop it right away. Connect to the QMP socket and you
>     won't get qmp's greeting
> 
>  2. Start qemu, connect to the QMP socket and run the qmp_capabilities
>     command. Then stop qemu and disconnect from the qmp socket and connect
>     again: you'll see you're still in the previous session
> 
> I do not get this with qemu 1.0.
> 
> Dietmar got this because the suspend command automatically stops the VM
> after migration...
> 
> Bisecting...

Didn't try to understand what's wrong with it, but bisect brings:

commit ac4119c023c72b15f54238af43e4a178fcf41494
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Fri Oct 12 09:52:49 2012 +0200

    chardev: Use timer instead of bottom-half to postpone open event
    
    As the block layer may decide to flush bottom-halfs while the machine is
    still initializing (e.g. to read geometry data from the disk), our
    postponed open event may be processed before the last frontend
    registered with a muxed chardev.
    
    Until the semantics of BHs have been clarified, use an expired timer to
    achieve the same effect (suggested by Paolo Bonzini). This requires to
    perform the alarm timer initialization earlier as otherwise timer
    subsystem can be used before being ready.
    
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>