From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eur3p-0000Xu-1R for qemu-devel@nongnu.org; Sat, 10 Mar 2018 21:50:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eur3l-0006r6-RI for qemu-devel@nongnu.org; Sat, 10 Mar 2018 21:50:09 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:55194 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eur3l-0006qu-N4 for qemu-devel@nongnu.org; Sat, 10 Mar 2018 21:50:05 -0500 References: <20180309090006.10018-1-peterx@redhat.com> <20180309090006.10018-24-peterx@redhat.com> From: Eric Blake Message-ID: Date: Sat, 10 Mar 2018 20:49:42 -0600 MIME-Version: 1.0 In-Reply-To: <20180309090006.10018-24-peterx@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v8 23/23] tests: qmp-test: add oob test List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Xu , qemu-devel@nongnu.org Cc: Stefan Hajnoczi , "Daniel P . Berrange" , Paolo Bonzini , Fam Zheng , Juan Quintela , mdroth@linux.vnet.ibm.com, Laurent Vivier , Markus Armbruster , marcandre.lureau@redhat.com, "Dr . David Alan Gilbert" On 03/09/2018 03:00 AM, Peter Xu wrote: > Test the new OOB capability. Here we used the new "x-oob-test" command. > Firstly, we send a lock=true and oob=false command to hang the main s/Firstly/First/ > thread. Then send another lock=false and oob=true command (which will > be run inside parser this time) to free that hanged command. > > Reviewed-by: Stefan Hajnoczi > Signed-off-by: Peter Xu > --- > tests/qmp-test.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > > + /* Now, enable OOB in current QMP session, it should success. */ s/success/succeed/ > + > + /* > + * Firstly send the "x-oob-test" command with lock=true and s/Firstly/First/ > + * oob=false, it should hang the dispatcher and main thread; > + * later, we send another lock=false with oob=true to continue > + * that thread processing. Finally we should receive replies from > + * both commands. > + */ > + qmp_async("{ 'execute': 'x-oob-test'," > + " 'arguments': { 'lock': true }, " > + " 'id': 'lock-cmd'}"); > + qmp_async("{ 'execute': 'x-oob-test', " > + " 'arguments': { 'lock': false }, " > + " 'control': { 'run-oob': true }, " > + " 'id': 'unlock-cmd' }"); > + > + /* Ignore all events. Wait for 2 acks */ > + while (acks < 2) { > + resp = qmp_receive(); > + cmd_id = qdict_get_str(resp, "id"); > + if (!g_strcmp0(cmd_id, "lock-cmd") || > + !g_strcmp0(cmd_id, "unlock-cmd")) { > + acks++; > + } > + QDECREF(resp); > + } Can you make the reply order deterministic? Perhaps by having the lock command insert a sleep after locking but before replying, so that the unlock always gets to reply first? But that can be a followup. Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org