From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaFP-0003OU-FX for qemu-devel@nongnu.org; Thu, 22 Nov 2012 12:07:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbaFJ-0001Hc-Hu for qemu-devel@nongnu.org; Thu, 22 Nov 2012 12:07:31 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:45270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaFJ-0001HY-Ae for qemu-devel@nongnu.org; Thu, 22 Nov 2012 12:07:25 -0500 Received: by mail-wi0-f171.google.com with SMTP id hn14so738015wib.10 for ; Thu, 22 Nov 2012 09:07:24 -0800 (PST) Sender: Paolo Bonzini Message-ID: <50AE5BC9.5080809@redhat.com> Date: Thu, 22 Nov 2012 18:07:21 +0100 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <20121122145825.2da0c10f@doriath.home> Content-Type: text/plain; charset=ISO-8859-1 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: Luiz Capitulino Cc: jan.kiszka@siemens.com, Dietmar Maurer , "qemu-devel@nongnu.org" 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. Paolo