[{"id":1771420,"web_url":"http://patchwork.ozlabs.org/comment/1771420/","msgid":"<5c8217a4-c169-c580-f461-e7173a772e31@redhat.com>","list_archive_url":null,"date":"2017-09-19T21:35:28","subject":"Re: [Qemu-devel] [RFC 07/15] monitor: unify global init","submitter":{"id":6591,"url":"http://patchwork.ozlabs.org/api/people/6591/","name":"Eric Blake","email":"eblake@redhat.com"},"content":"On 09/14/2017 02:50 AM, Peter Xu wrote:\n> There are many places for monitor init its globals, at least:\n> \n> - monitor_init_qmp_commands() at the very beginning\n> - single function to init monitor_lock\n> - in the first entry of monitor_init() using \"is_first_init\"\n> \n> Unify them a bit.\n> \n> Signed-off-by: Peter Xu \n> ---\n> include/monitor/monitor.h | 2 +-\n> monitor.c | 25 ++++++++++---------------\n> vl.c | 3 ++-\n> 3 files changed, 13 insertions(+), 17 deletions(-)\n> \n\n> \n> +void monitor_init_globals(void)\n> +{\n> + monitor_init_qmp_commands();\n> + monitor_qapi_event_init();\n> + sortcmdlist();\n> + qemu_mutex_init(&monitor_lock);\n> +}\n\nAre we sure that this new function is called sooner than any access to\nmonitor_lock,\n\n> -static void __attribute__((constructor)) monitor_lock_init(void)\n> -{\n> - qemu_mutex_init(&monitor_lock);\n> -}\n\nespecially since the old code initialized the lock REALLY early?\n\n> diff --git a/vl.c b/vl.c\n> index fb1f05b..850cf55 100644\n> --- a/vl.c\n> +++ b/vl.c\n> @@ -3049,7 +3049,6 @@ int main(int argc, char **argv, char **envp)\n> qemu_init_exec_dir(argv[0]);\n> \n> module_call_init(MODULE_INIT_QOM);\n> - monitor_init_qmp_commands();\n> \n> qemu_add_opts(&qemu_drive_opts);\n> qemu_add_drive_opts(&qemu_legacy_drive_opts);\n> @@ -4587,6 +4586,8 @@ int main(int argc, char **argv, char **envp)\n> \n> parse_numa_opts(current_machine);\n> \n> + monitor_init_globals();\n> +\n\nPre-patch, a breakpoint on main() and on monitor_lock_init() fires on\nmonitor_lock_init() first, prior to main.\n\nBreakpoint 2, monitor_lock_init () at /home/eblake/qemu/monitor.c:4089\n4089\t qemu_mutex_init(&monitor_lock);\n(gdb) c\nContinuing.\n[New Thread 0x7fffce225700 (LWP 26380)]\n\nThread 1 \"qemu-system-x86\" hit Breakpoint 1, main (argc=5,\n argv=0x7fffffffdc88, envp=0x7fffffffdcb8) at vl.c:3077\n3077\t{\n\nPost-patch, the mutex is not initialized until well after main(). So\nthe real question is what (if anything) is using the lock in between\nthose two points?\n\nHmm - it may be that we needed it back before commit 05875687, when we\nreally did depend on MODULE_INIT_QAPI, but it is something we forgot to\ncleanup in the meantime?\n\nIf nothing else, the commit message should call out that dropping\n__attribute__((constructor)) nonsense is intentional (if it was indeed\nnonsense).","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=eblake@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxbm22HJJz9sNr\n\tfor ;\n\tWed, 20 Sep 2017 07:36:18 +1000 (AEST)","from localhost ([::1]:45549 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duQBk-0004hs-8r\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 17:36:16 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:34382)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duQBC-0004gT-Qd\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 17:35:44 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duQB8-0003Jj-1J\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 17:35:42 -0400","from mx1.redhat.com ([209.132.183.28]:39171)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1duQB7-0003IN-JH\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 17:35:37 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 111FB80476;\n\tTue, 19 Sep 2017 21:35:36 +0000 (UTC)","from [10.10.124.97] (ovpn-124-97.rdu2.redhat.com [10.10.124.97])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 16A3B60619;\n\tTue, 19 Sep 2017 21:35:29 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 111FB80476","To":"Peter Xu , qemu-devel@nongnu.org","References":"<1505375436-28439-1-git-send-email-peterx@redhat.com>\n\t<1505375436-28439-8-git-send-email-peterx@redhat.com>","From":"Eric Blake ","Openpgp":"url=http://people.redhat.com/eblake/eblake.gpg","Organization":"Red Hat, Inc.","Message-ID":"<5c8217a4-c169-c580-f461-e7173a772e31@redhat.com>","Date":"Tue, 19 Sep 2017 16:35:28 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<1505375436-28439-8-git-send-email-peterx@redhat.com>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"dMNNCEejEL63WTt6AISou49d6G352fa5a\"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.28]);\n\tTue, 19 Sep 2017 21:35:36 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","X-Content-Filtered-By":"Mailman/MimeDel 2.1.21","Subject":"Re: [Qemu-devel] [RFC 07/15] monitor: unify global init","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Laurent Vivier , Fam Zheng , Juan\n\tQuintela , Markus Armbruster ,\n\tmdroth@linux.vnet.ibm.com, \tStefan Hajnoczi ,\n\t=?utf-8?q?Marc-Andr=C3=A9_Lure?= =?utf-8?q?au?=\n\t, \tPaolo Bonzini ,\n\t\"Dr . David Alan Gilbert\" ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771424,"web_url":"http://patchwork.ozlabs.org/comment/1771424/","msgid":"","list_archive_url":null,"date":"2017-09-19T21:48:35","subject":"Re: [Qemu-devel] [RFC 07/15] monitor: unify global init","submitter":{"id":6591,"url":"http://patchwork.ozlabs.org/api/people/6591/","name":"Eric Blake","email":"eblake@redhat.com"},"content":"On 09/19/2017 04:35 PM, Eric Blake wrote:\n> On 09/14/2017 02:50 AM, Peter Xu wrote:\n>> There are many places for monitor init its globals, at least:\n>>\n\n> Are we sure that this new function is called sooner than any access to\n> monitor_lock,\n> \n>> -static void __attribute__((constructor)) monitor_lock_init(void)\n>> -{\n>> - qemu_mutex_init(&monitor_lock);\n>> -}\n> \n> especially since the old code initialized the lock REALLY early?\n\n(Partially) answering myself:\n\n> \n> Pre-patch, a breakpoint on main() and on monitor_lock_init() fires on\n> monitor_lock_init() first, prior to main.\n> \n> Breakpoint 2, monitor_lock_init () at /home/eblake/qemu/monitor.c:4089\n> 4089\t qemu_mutex_init(&monitor_lock);\n> (gdb) c\n> Continuing.\n> [New Thread 0x7fffce225700 (LWP 26380)]\n> \n> Thread 1 \"qemu-system-x86\" hit Breakpoint 1, main (argc=5,\n> argv=0x7fffffffdc88, envp=0x7fffffffdcb8) at vl.c:3077\n> 3077\t{\n\nAlso, pre-patch, 'watch monitor_lock.initialized' and 'watch\nmonitor_lock.lock.__data.__lock' show that the lock is first utilized at:\n\n(gdb) bt\n#0 0x00007fffdac59e12 in __GI___pthread_mutex_lock\n(mutex=0x555556399340 ) at ../nptl/pthread_mutex_lock.c:80\n#1 0x0000555555ce01ed in qemu_mutex_lock (mutex=0x555556399340\n)\n at util/qemu-thread-posix.c:65\n#2 0x00005555557bc8b8 in monitor_init (chr=0x55555690bf70, flags=4)\n at /home/eblake/qemu/monitor.c:4126\n#3 0x000055555591ae80 in mon_init_func (opaque=0x0,\nopts=0x55555688e3d0, errp=0x0) at vl.c:2482\n#4 0x0000555555cf3e63 in qemu_opts_foreach (list=0x555556225200\n, func=0x55555591ad33 , opaque=0x0, errp=0x0)\n at util/qemu-option.c:1104\n#5 0x0000555555920128 in main (argc=5, argv=0x7fffffffdc88,\nenvp=0x7fffffffdcb8) at vl.c:4670\n\nand double-checking qemu_mutex_lock, our .initialized member provides\nNICE runtime checking that we don't use an uninitialized lock. So the\nfact that your patch doesn't assert means your later initialization is\nstill fine.\n\n[TIL: the gdb 'watch' command is cool, but it's better if you watch only\n4 or 8 bytes at a time; I first tried 'watch monitor_lock', but that's\nhundreds of times slower as hardware can't watch that much data at once,\nat which point gdb emulates it by single-stepping the entire program]\n\n> \n> Post-patch, the mutex is not initialized until well after main(). So\n> the real question is what (if anything) is using the lock in between\n> those two points?\n\nAccording to gdb watchpoints, no.\n\n> \n> Hmm - it may be that we needed it back before commit 05875687, when we\n> really did depend on MODULE_INIT_QAPI, but it is something we forgot to\n> cleanup in the meantime?\n\nSo what I didn't debug was whether the constructor attribute was\nmandatory in the past, and if so, which commit made it no longer\nmandatory (my mention of commit 05875687 is only a guess).\n\n> \n> If nothing else, the commit message should call out that dropping\n> __attribute__((constructor)) nonsense is intentional (if it was indeed\n> nonsense).\n> \n\nThis part is still true.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=eblake@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxc2x27CHz9s8J\n\tfor ;\n\tWed, 20 Sep 2017 07:49:12 +1000 (AEST)","from localhost ([::1]:45614 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duQOD-0002et-MO\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 17:49:09 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:42159)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duQNt-0002eZ-89\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 17:48:50 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duQNp-00036A-Bg\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 17:48:49 -0400","from mx1.redhat.com ([209.132.183.28]:46816)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1duQNp-00035g-2X\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 17:48:45 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id B766A356D4;\n\tTue, 19 Sep 2017 21:48:43 +0000 (UTC)","from [10.10.124.97] (ovpn-124-97.rdu2.redhat.com [10.10.124.97])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 844285D6A4;\n\tTue, 19 Sep 2017 21:48:36 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com B766A356D4","To":"Peter Xu , qemu-devel@nongnu.org","References":"<1505375436-28439-1-git-send-email-peterx@redhat.com>\n\t<1505375436-28439-8-git-send-email-peterx@redhat.com>\n\t<5c8217a4-c169-c580-f461-e7173a772e31@redhat.com>","From":"Eric Blake ","Openpgp":"url=http://people.redhat.com/eblake/eblake.gpg","Organization":"Red Hat, Inc.","Message-ID":"","Date":"Tue, 19 Sep 2017 16:48:35 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<5c8217a4-c169-c580-f461-e7173a772e31@redhat.com>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"goeLLfjMWXDnDLQ2uB5feWBwaHb9D0jNA\"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.30]);\n\tTue, 19 Sep 2017 21:48:43 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","X-Content-Filtered-By":"Mailman/MimeDel 2.1.21","Subject":"Re: [Qemu-devel] [RFC 07/15] monitor: unify global init","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Laurent Vivier , Fam Zheng , Juan\n\tQuintela , mdroth@linux.vnet.ibm.com, Markus\n\tArmbruster , Stefan Hajnoczi ,\n\tPaolo Bonzini , =?utf-8?q?Marc-Andr=C3=A9_Lureau?=\n\t, \"Dr . David Alan Gilbert\"\n\t","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771626,"web_url":"http://patchwork.ozlabs.org/comment/1771626/","msgid":"<20170920065434.GW3617@pxdev.xzpeter.org>","list_archive_url":null,"date":"2017-09-20T06:54:34","subject":"Re: [Qemu-devel] [RFC 07/15] monitor: unify global init","submitter":{"id":67717,"url":"http://patchwork.ozlabs.org/api/people/67717/","name":"Peter Xu","email":"peterx@redhat.com"},"content":"On Tue, Sep 19, 2017 at 04:48:35PM -0500, Eric Blake wrote:\n> On 09/19/2017 04:35 PM, Eric Blake wrote:\n> > On 09/14/2017 02:50 AM, Peter Xu wrote:\n> >> There are many places for monitor init its globals, at least:\n> >>\n> \n> > Are we sure that this new function is called sooner than any access to\n> > monitor_lock,\n> > \n> >> -static void __attribute__((constructor)) monitor_lock_init(void)\n> >> -{\n> >> - qemu_mutex_init(&monitor_lock);\n> >> -}\n> > \n> > especially since the old code initialized the lock REALLY early?\n> \n> (Partially) answering myself:\n> \n> > \n> > Pre-patch, a breakpoint on main() and on monitor_lock_init() fires on\n> > monitor_lock_init() first, prior to main.\n> > \n> > Breakpoint 2, monitor_lock_init () at /home/eblake/qemu/monitor.c:4089\n> > 4089\t qemu_mutex_init(&monitor_lock);\n> > (gdb) c\n> > Continuing.\n> > [New Thread 0x7fffce225700 (LWP 26380)]\n> > \n> > Thread 1 \"qemu-system-x86\" hit Breakpoint 1, main (argc=5,\n> > argv=0x7fffffffdc88, envp=0x7fffffffdcb8) at vl.c:3077\n> > 3077\t{\n> \n> Also, pre-patch, 'watch monitor_lock.initialized' and 'watch\n> monitor_lock.lock.__data.__lock' show that the lock is first utilized at:\n> \n> (gdb) bt\n> #0 0x00007fffdac59e12 in __GI___pthread_mutex_lock\n> (mutex=0x555556399340 ) at ../nptl/pthread_mutex_lock.c:80\n> #1 0x0000555555ce01ed in qemu_mutex_lock (mutex=0x555556399340\n> )\n> at util/qemu-thread-posix.c:65\n> #2 0x00005555557bc8b8 in monitor_init (chr=0x55555690bf70, flags=4)\n> at /home/eblake/qemu/monitor.c:4126\n> #3 0x000055555591ae80 in mon_init_func (opaque=0x0,\n> opts=0x55555688e3d0, errp=0x0) at vl.c:2482\n> #4 0x0000555555cf3e63 in qemu_opts_foreach (list=0x555556225200\n> , func=0x55555591ad33 , opaque=0x0, errp=0x0)\n> at util/qemu-option.c:1104\n> #5 0x0000555555920128 in main (argc=5, argv=0x7fffffffdc88,\n> envp=0x7fffffffdcb8) at vl.c:4670\n> \n> and double-checking qemu_mutex_lock, our .initialized member provides\n> NICE runtime checking that we don't use an uninitialized lock. So the\n> fact that your patch doesn't assert means your later initialization is\n> still fine.\n\nYeah, that's something I liked as well.\n\n> \n> [TIL: the gdb 'watch' command is cool, but it's better if you watch only\n> 4 or 8 bytes at a time; I first tried 'watch monitor_lock', but that's\n> hundreds of times slower as hardware can't watch that much data at once,\n> at which point gdb emulates it by single-stepping the entire program]\n\nGood to learn it!\n\nThanks for digging the whole thing up.\n\n> \n> > \n> > Post-patch, the mutex is not initialized until well after main(). So\n> > the real question is what (if anything) is using the lock in between\n> > those two points?\n> \n> According to gdb watchpoints, no.\n> \n> > \n> > Hmm - it may be that we needed it back before commit 05875687, when we\n> > really did depend on MODULE_INIT_QAPI, but it is something we forgot to\n> > cleanup in the meantime?\n> \n> So what I didn't debug was whether the constructor attribute was\n> mandatory in the past, and if so, which commit made it no longer\n> mandatory (my mention of commit 05875687 is only a guess).\n> \n> > \n> > If nothing else, the commit message should call out that dropping\n> > __attribute__((constructor)) nonsense is intentional (if it was indeed\n> > nonsense).\n> > \n> \n> This part is still true.\n\nIf this patch is doable, I'll add explicit reason to commit message.\n\nPaolo/Markus, would any of you help confirm this change? (considering\nPaolo introduced commit d622cb587)\n\nOne thing I slightly not sure of is that, some device realization has\nthis code path (take fsl_imx25_realize() as example):\n\n fsl_imx25_realize\n qemu_chr_new\n qemu_chr_new_noreplay\n char is_mux?\n monitor_init\n\n(note: I never know why we create the monitor in chardev\n creation... would there be a better place?)\n\nEspecially considering some integrated devices can be created along\nwith machine init.\n\nAnyway, this patch was trying to cleanup the things a bit, and also\nmore convenient for me to add new codes upon. If any of us think it's\nnot safe enough, please say explicitly, and I can drop it and do the\nrest in \"the ugly way\".\n\nThanks,","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx05.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx05.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=peterx@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxr8y5Sqzz9s7h\n\tfor ;\n\tWed, 20 Sep 2017 16:55:13 +1000 (AEST)","from localhost ([::1]:47064 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duYuc-0000P3-Ep\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 02:55:10 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:39868)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duYuK-0000Oe-CS\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:54:53 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duYuB-0001Er-V0\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:54:48 -0400","from mx1.redhat.com ([209.132.183.28]:36058)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1duYuB-0001Cb-MR\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:54:43 -0400","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id C48AF34C1;\n\tWed, 20 Sep 2017 06:54:41 +0000 (UTC)","from pxdev.xzpeter.org (dhcp-15-224.nay.redhat.com [10.66.15.224])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id B348A5C541;\n\tWed, 20 Sep 2017 06:54:36 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com C48AF34C1","Date":"Wed, 20 Sep 2017 14:54:34 +0800","From":"Peter Xu ","To":"Eric Blake ","Message-ID":"<20170920065434.GW3617@pxdev.xzpeter.org>","References":"<1505375436-28439-1-git-send-email-peterx@redhat.com>\n\t<1505375436-28439-8-git-send-email-peterx@redhat.com>\n\t<5c8217a4-c169-c580-f461-e7173a772e31@redhat.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.29]);\n\tWed, 20 Sep 2017 06:54:41 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [RFC 07/15] monitor: unify global init","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Laurent Vivier , Fam Zheng , Juan\n\tQuintela , qemu-devel@nongnu.org, Markus Armbruster\n\t, mdroth@linux.vnet.ibm.com, Stefan Hajnoczi\n\t, Paolo Bonzini , \n\t=?utf-8?q?Marc-Andr=C3=A9?= Lureau ,\n\t\"Dr . David Alan Gilbert\" ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]