From: Peter Xu <peterx@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <shajnocz@redhat.com>,
"Daniel P . Berrange" <berrange@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <famz@redhat.com>,
Juan Quintela <quintela@redhat.com>,
mdroth@linux.vnet.ibm.com, Eric Blake <eblake@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
marcandre.lureau@redhat.com
Subject: Re: [Qemu-devel] [RFC v4 21/27] qmp: let migrate-incoming allow out-of-band
Date: Mon, 27 Nov 2017 13:20:03 +0800 [thread overview]
Message-ID: <20171127052003.GB5153@xz-mi> (raw)
In-Reply-To: <20171124131452.GD2302@work-vm>
On Fri, Nov 24, 2017 at 01:14:53PM +0000, Dr. David Alan Gilbert wrote:
> * Peter Xu (peterx@redhat.com) wrote:
> > So it can get rid of being run on main thread.
> >
> > Signed-off-by: Peter Xu <peterx@redhat.com>
>
> Last time I asked if you were sure that we didn't do locking,
> and you explained that we end up just setting up a callback
> that happens in the mainloop, and this shouldn't take a lock.
> I confirmed this by:
>
> running with -incoming defer
> breakpointing in hmp_migrate_incoming
> doing migrate_incoming tcp:0:4444
> once I hit that breakpointing adding two more breakpoints:
> a) qemu_mutex_lock_iothread
> b) the end of hmp's handle_hmp_command
>
> and indeed it hit the end of handle_hmp_command without
> having hit the qemu_mutex_lock_iothread; so initially that
> looks ok.
I am not sure I fully understand the test above - I think it was
trying to verify the whole OOB thing running without BQL? If so,
there are possibly two things missing:
Firstly, qemu_mutex_lock_iothread() is actually called before we call
hmp_migrate_incoming(). To verify it is simple: just break at entry of
hmp_migrate_incoming() and do "p iothread_locked", it'll be true (I
would always prefer printing that global variable to know whether
current thread is in a BQL section).
Secondly, HMP will still always take the BQL; this patch only enables
OOB for QMP command "migrate-incoming" rather than the HMP command. So
IMHO what we need to test is QMP command, rather than this HMP one.
To test that QMP command, it's still not that easy (actually awkward).
We need to first enable "OOB" when doing handshake for QMP:
{"execute": "qmp_capabilities", "arguments": { "enable": [ "oob" ] } }
Then, we need to send the command with proper "id"/"control" field:
{ "execute": "migrate-incoming",
"arguments": { "uri": "tcp:localhost:1234" },
"control": { "run-oob": true },
"id": "test-command" }
Note that here "id" field will be a must now since OOB requires that,
meanwhile the "control" field is a must too to make sure that is run
in OOB format (otherwise this command will still take BQL and run as
usual). So if you see we do have a lot of protection to make sure we
only run OOB only if we really wanted to... otherwise we'll always run
in compatible and old way.
This time if we break at qmp_migrate_incoming() and then do "p
iothread_locked", we should see a false here.
>
> But then I added a break on pthread_mutex_lock, and I've got
> this set caused by qemu_start_incoming_migration sending a
> MIGRATION_STATUS_SETUP event:
>
> #1 0x0000555555ba6eba in qemu_mutex_lock (mutex=mutex@entry=0x5555563f9ba0 <monitor_lock>)
> at /home/dgilbert/git/qemu/util/qemu-thread-posix.c:65
> #2 0x00005555557f01c1 in monitor_qapi_event_queue (event=QAPI_EVENT_MIGRATION, qdict=0x555557d93c00, errp=<optimized out>) at /home/dgilbert/git/qemu/monitor.c:442
>
> 440 trace_monitor_protocol_event_queue(event, qdict, evconf->rate);
> 441
> 442 qemu_mutex_lock(&monitor_lock);
> 443
>
> #3 0x0000555555b92722 in qapi_event_send_migration (status=status@entry=MIGRATION_STATUS_SETUP, errp=0x555556859320 <error_abort>) at qapi-event.c:661
> #4 0x0000555555a6159f in qemu_start_incoming_migration (uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc700)
> at /home/dgilbert/git/qemu/migration/migration.c:253
> #5 0x0000555555a641c5 in qmp_migrate_incoming (uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc730)
> at /home/dgilbert/git/qemu/migration/migration.c:1321
>
> is there anything which protects us there?
IIUC you mean what if we e.g. page fault during taking the
monitor_lock? IMHO it just can't happen - monitor_lock is really used
in limited places and during those critical sections there is no guest
memory access at all (which only protects the monitor logic itself
AFAICT).
Thanks,
>
> Dave
>
> > ---
> > qapi/migration.json | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/qapi/migration.json b/qapi/migration.json
> > index bbc4671ded..95098072dd 100644
> > --- a/qapi/migration.json
> > +++ b/qapi/migration.json
> > @@ -1063,7 +1063,8 @@
> > # <- { "return": {} }
> > #
> > ##
> > -{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } }
> > +{ 'command': 'migrate-incoming', 'data': {'uri': 'str' },
> > + 'allow-oob': true }
> >
> > ##
> > # @xen-save-devices-state:
> > --
> > 2.13.6
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
--
Peter Xu
next prev parent reply other threads:[~2017-11-27 5:20 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 13:05 [Qemu-devel] [RFC v4 00/27] QMP: out-of-band (OOB) execution support Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 01/27] qobject: introduce qstring_get_try_str() Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 02/27] qobject: introduce qobject_get_try_str() Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 03/27] qobject: let object_property_get_str() use new API Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 04/27] monitor: move skip_flush into monitor_data_init Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 05/27] qjson: add "opaque" field to JSONMessageParser Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 06/27] monitor: move the cur_mon hack deeper for QMP Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 07/27] monitor: unify global init Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 08/27] monitor: let mon_list be tail queue Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 09/27] monitor: create monitor dedicate iothread Peter Xu
2017-11-23 10:46 ` Dr. David Alan Gilbert
2017-11-23 10:51 ` Dr. David Alan Gilbert
2017-11-23 10:53 ` Daniel P. Berrange
2017-11-24 7:36 ` Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 10/27] monitor: allow to use IO thread for parsing Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 11/27] qmp: introduce QMPCapability Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 12/27] qmp: negociate QMP capabilities Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 13/27] qmp: introduce some capability helpers Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 14/27] monitor: introduce monitor_qmp_respond() Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 15/27] monitor: let monitor_{suspend|resume} thread safe Peter Xu
2017-11-23 11:23 ` Dr. David Alan Gilbert
2017-11-24 7:58 ` Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 16/27] monitor: separate QMP parser and dispatcher Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 17/27] qmp: add new event "request-dropped" Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 18/27] monitor: send event when request queue full Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 19/27] qapi: introduce new cmd option "allow-oob" Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 20/27] qmp: support out-of-band (oob) execution Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 21/27] qmp: let migrate-incoming allow out-of-band Peter Xu
2017-11-24 13:14 ` Dr. David Alan Gilbert
2017-11-27 5:20 ` Peter Xu [this message]
2017-11-27 10:44 ` Dr. David Alan Gilbert
2017-11-27 10:54 ` Peter Xu
2017-11-27 11:04 ` Dr. David Alan Gilbert
2017-11-27 11:26 ` Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 22/27] qmp: isolate responses into io thread Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 23/27] monitor: enable IO thread for (qmp & !mux) typed Peter Xu
2017-11-24 11:01 ` Dr. David Alan Gilbert
2017-11-27 3:00 ` Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 24/27] qmp: add command "x-oob-test" Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 25/27] docs: update QMP documents for OOB commands Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 26/27] tests: qmp-test: verify command batching Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 27/27] tests: qmp-test: add oob test Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171127052003.GB5153@xz-mi \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=shajnocz@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).