From patchwork Thu Nov 22 17:09:44 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kiszka X-Patchwork-Id: 201100 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 495F92C00A6 for ; Fri, 23 Nov 2012 04:59:41 +1100 (EST) Received: from localhost ([::1]:41666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaIC-00084P-L0 for incoming@patchwork.ozlabs.org; Thu, 22 Nov 2012 12:10:24 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaHg-0006zD-DD for qemu-devel@nongnu.org; Thu, 22 Nov 2012 12:09:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbaHa-0002JK-F0 for qemu-devel@nongnu.org; Thu, 22 Nov 2012 12:09:52 -0500 Received: from david.siemens.de ([192.35.17.14]:25244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbaHa-0002J9-4W for qemu-devel@nongnu.org; Thu, 22 Nov 2012 12:09:46 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id qAMH9iFV003430; Thu, 22 Nov 2012 18:09:44 +0100 Received: from mchn199C.mchp.siemens.de ([139.25.109.49]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id qAMH9iKh001053; Thu, 22 Nov 2012 18:09:44 +0100 Message-ID: <50AE5C58.8030204@siemens.com> Date: Thu, 22 Nov 2012 18:09:44 +0100 From: Jan Kiszka User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Paolo Bonzini 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> In-Reply-To: <50AE5BC9.5080809@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 192.35.17.14 Cc: "qemu-devel@nongnu.org" , Dietmar Maurer , Luiz Capitulino Subject: Re: [Qemu-devel] qmp problems with --enable-kvm X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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? Jan 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); } }