From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaVZ-00054Y-BC for qemu-devel@nongnu.org; Thu, 22 Nov 2012 12:24:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbaVX-0006NA-Ow for qemu-devel@nongnu.org; Thu, 22 Nov 2012 12:24:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaVX-0006Lz-Gu for qemu-devel@nongnu.org; Thu, 22 Nov 2012 12:24:11 -0500 Date: Thu, 22 Nov 2012 15:24:01 -0200 From: Luiz Capitulino Message-ID: <20121122152401.614183f6@doriath.home> In-Reply-To: <50AE5C58.8030204@siemens.com> References: <24E144B8C0207547AD09C467A8259F755782E999@lisa.maurer-it.com> <20121122112026.405709d8@doriath.home> <50AE4640.3000604@redhat.com> <24E144B8C0207547AD09C467A8259F755782EC31@lisa.maurer-it.com> <50AE4C32.6050309@redhat.com> <24E144B8C0207547AD09C467A8259F755782ECC5@lisa.maurer-it.com> <50AE4E34.40105@redhat.com> <20121122142414.3f97883a@doriath.home> <20121122143324.27c55bce@doriath.home> <20121122145825.2da0c10f@doriath.home> <50AE5BC9.5080809@redhat.com> <50AE5C58.8030204@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qmp problems with --enable-kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , Dietmar Maurer , "qemu-devel@nongnu.org" On Thu, 22 Nov 2012 18:09:44 +0100 Jan Kiszka 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 > >> 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 > > > > 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 > > 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 >