From: Fam Zheng <famz@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Juan Quintela <quintela@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread
Date: Tue, 22 Aug 2017 12:15:19 +0800 [thread overview]
Message-ID: <20170822041519.GC2146@lemon> (raw)
In-Reply-To: <20170822025654.GE30356@pxdev.xzpeter.org>
On Tue, 08/22 10:56, Peter Xu wrote:
> I haven't really encountered (c), but I think it's the migrate_cancel
> command that matters, which should not need BQL as well.
There is bdrv_invalidate_cache_all() in migrate_cancel which clearly isn't safe.
Is that if block unreachable in this case? If so we should assert, otherwise
this command is not okay to run without BQL.
Generically, what guarantee the thread-safety of a qmp command when you decide
BQL is not needed? In other words, how do you prove commands are safe without
BQL? I think almost every command accesses global state, but lock-free data
structures are rare AFAICT.
Fam
next prev parent reply other threads:[~2017-08-22 4:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-21 7:44 [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread Peter Xu
2017-08-21 7:44 ` [Qemu-devel] [RFC 1/6] monitor: move skip_flush into monitor_data_init Peter Xu
2017-08-21 7:44 ` [Qemu-devel] [RFC 2/6] monitor: allow monitor to create thread to poll Peter Xu
2017-08-21 7:44 ` [Qemu-devel] [RFC 3/6] QAPI: new QMP command option "without-bql" Peter Xu
2017-08-21 7:44 ` [Qemu-devel] [RFC 4/6] migration: qmp: migrate_incoming don't need BQL Peter Xu
2017-08-21 7:44 ` [Qemu-devel] [RFC 5/6] hmp: support "without_bql" Peter Xu
2017-08-21 7:44 ` [Qemu-devel] [RFC 6/6] migration: hmp: migrate_incoming don't need BQL Peter Xu
2017-08-21 8:58 ` [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread Fam Zheng
2017-08-21 10:05 ` Peter Xu
2017-08-21 10:17 ` Dr. David Alan Gilbert
2017-08-21 14:04 ` Fam Zheng
2017-08-21 14:06 ` Dr. David Alan Gilbert
2017-08-21 13:57 ` Fam Zheng
2017-08-21 15:36 ` Dr. David Alan Gilbert
2017-08-21 16:54 ` Fam Zheng
2017-08-21 17:28 ` Dr. David Alan Gilbert
2017-08-22 2:15 ` Fam Zheng
2017-08-22 2:56 ` Peter Xu
2017-08-22 4:15 ` Fam Zheng [this message]
2017-08-22 5:59 ` Peter Xu
2017-08-22 6:33 ` Fam Zheng
2017-08-22 6:56 ` Peter Xu
2017-08-22 8:29 ` Dr. David Alan Gilbert
2017-08-22 8:48 ` Fam Zheng
2017-08-22 8:48 ` Dr. David Alan Gilbert
2017-08-22 4:51 ` no-reply
2017-08-22 6:21 ` 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=20170822041519.GC2146@lemon \
--to=famz@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=lvivier@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@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).