From nobody Sun May 5 17:26:00 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1528738611071396.2002941479618; Mon, 11 Jun 2018 10:36:51 -0700 (PDT) Received: from localhost ([::1]:50488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSQkM-0005lr-9M for importer@patchew.org; Mon, 11 Jun 2018 13:36:50 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSQiX-0004jB-MF for qemu-devel@nongnu.org; Mon, 11 Jun 2018 13:34:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fSQiW-0005Pu-Mf for qemu-devel@nongnu.org; Mon, 11 Jun 2018 13:34:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37958) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fSQiW-0005Pc-Ed for qemu-devel@nongnu.org; Mon, 11 Jun 2018 13:34:56 -0400 Received: from smtp.corp.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AB98D30C1114; Mon, 11 Jun 2018 17:34:55 +0000 (UTC) Received: from localhost (ovpn-116-19.gru2.redhat.com [10.97.116.19]) by smtp.corp.redhat.com (Postfix) with ESMTP id 43367300166D; Mon, 11 Jun 2018 17:34:55 +0000 (UTC) From: Eduardo Habkost To: Peter Maydell , qemu-devel@nongnu.org Date: Mon, 11 Jun 2018 14:34:52 -0300 Message-Id: <20180611173452.28087-2-ehabkost@redhat.com> In-Reply-To: <20180611173452.28087-1-ehabkost@redhat.com> References: <20180611173452.28087-1-ehabkost@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Mon, 11 Jun 2018 17:34:55 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 1/1] cli: Don't run early event loop if no --preconfig was specified X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , Igor Mammedov Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Igor Mammedov After 047f7038f586d215 it is possible for event loop to run two times. First time whilst parsing command line options (the idea is to bring up monitor early so that management applications can tweak config before machine is initialized). And the second time is after everything is set up (this is the usual place). In both cases the event loop is called as main_loop_wait(nonblocking =3D false) which causes the event loop to block until at least one event occurred. Now, consider that somebody (i.e. libvirt) calls us with -daemonize. This operation is split in two steps. The main() calls os_daemonize() which fork()-s and then waits in read() until child notifies it via write(): /qemu.git $ ./x86_64-softmmu/qemu-system-x86_64 -S -daemonize \ -no-user-config -nodefaults -nographic main(): child: os_daemonize(): read(pipe[0]) main_loop(): main_loop_wait(false) os_setup_post(): write(pipe[1]) main_loop(): main_loop_wait(false) Here it can be clearly seen that main() does not exit until an event occurs, but at the same time nobody will touch the monitor socket until their exec("qemu-system-*") finishes. So the whole thing deadlocks. The solution is to not call main_loop_wait() unless --preconfig was specified (in which case caller knows they must connect to the socket before exec() finishes). Patch also fixes hang when -nodefaults option is used, which were causing QEMU hang in the early main_loop_wait() indefinitely by the same means (not calling main_loop_wait() unless --preconfig is present on CLI) Based on From: Michal Privoznik Subject: [PATCH] cli: Don't run early event loop if no --preconfig was sp= ecified Message-Id: Fixes: 047f7038f586d215 Signed-off-by: Igor Mammedov Message-Id: <1528207243-268226-2-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost --- vl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/vl.c b/vl.c index 06031715ac..6e34fb348d 100644 --- a/vl.c +++ b/vl.c @@ -1841,7 +1841,7 @@ static void main_loop(void) #ifdef CONFIG_PROFILER int64_t ti; #endif - do { + while (!main_loop_should_exit()) { #ifdef CONFIG_PROFILER ti =3D profile_getclock(); #endif @@ -1849,7 +1849,7 @@ static void main_loop(void) #ifdef CONFIG_PROFILER dev_time +=3D profile_getclock() - ti; #endif - } while (!main_loop_should_exit()); + } } =20 static void version(void) --=20 2.18.0.rc1.1.g3f1ff2140