qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v8 23/23] tests: qmp-test: add oob test


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v8 23/23] tests: qmp-test: add oob test
Date: Sat, 10 Mar 2018 20:49:42 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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 <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
---
  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 <address@hidden>

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]