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

[Luiz Capitulino]

On Thu, 22 Nov 2012 18:09:44 +0100
Jan Kiszka <address@hidden> wrote:

> On 2012-11-22 18:07, Paolo Bonzini wrote:
> > Il 22/11/2012 17:58, Luiz Capitulino ha scritto:
> >>>>> 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 <address@hidden>
> >> 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 <address@hidden>
> > 
> > Ouch, in retrospect it actually makes sense since this patch uses a
> > vm_clock timer.  Elementary, Watson... :)
> > 
> > I don't think there is a fix, short of reverting this commit.
> 
> We have more timers than the one based on vm_clock. Does this help?

It helps to the point of fixing the issue to me :) Thanks!

Tested-by: Luiz Capitulino <address@hidden>

> 
> diff --git a/qemu-char.c b/qemu-char.c
> index 88f4025..242b799 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -134,9 +134,9 @@ static void qemu_chr_fire_open_event(void *opaque)
>  void qemu_chr_generic_open(CharDriverState *s)
>  {
>      if (s->open_timer == NULL) {
> -        s->open_timer = qemu_new_timer_ms(vm_clock,
> +        s->open_timer = qemu_new_timer_ms(rt_clock,
>                                            qemu_chr_fire_open_event, s);
> -        qemu_mod_timer(s->open_timer, qemu_get_clock_ms(vm_clock) - 1);
> +        qemu_mod_timer(s->open_timer, qemu_get_clock_ms(rt_clock) - 1);
>      }
>  }
>  
> Jan
>