From: "Pavel Dovgalyuk" <dovgaluk@ispras.ru>
To: 'Kevin Wolf' <kwolf@redhat.com>
Cc: edgar.iglesias@xilinx.com, peter.maydell@linaro.org,
igor.rubinov@gmail.com, mark.burton@greensocs.com,
real@ispras.ru, hines@cert.org, qemu-devel@nongnu.org,
maria.klimushenkova@ispras.ru, stefanha@redhat.com,
pbonzini@redhat.com, batuzovk@ispras.ru, alex.bennee@linaro.org,
fred.konrad@greensocs.com
Subject: Re: [Qemu-devel] [PATCH 3/3] replay: introduce block devices record/replay
Date: Mon, 15 Feb 2016 12:14:23 +0300 [thread overview]
Message-ID: <003a01d167d1$42df95f0$c89ec1d0$@ru> (raw)
In-Reply-To: <003301d167cc$4d7d9480$e878bd80$@ru>
> From: Pavel Dovgalyuk [mailto:dovgaluk@ispras.ru]
> > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > > >
> > > > int blkreplay_co_readv()
> > > > {
> > > > BlockReplayState *s = bs->opaque;
> > > > int reqid = s->reqid++;
> > > >
> > > > bdrv_co_readv(bs->file, ...);
> > > >
> > > > if (mode == record) {
> > > > log(reqid, time);
> > > > } else {
> > > > assert(mode == replay);
> > > > bool *done = req_replayed_list_get(reqid)
> > > > if (done) {
> > > > *done = true;
> > > > } else {
> > > point A
> > > > req_completed_list_insert(reqid, qemu_coroutine_self());
> > > > qemu_coroutine_yield();
> > > > }
> > > > }
> > > > }
> > > >
> > > > /* called by replay.c */
> > > > int blkreplay_run_event()
> > > > {
> > > > if (mode == replay) {
> > > > co = req_completed_list_get(e.reqid);
> > > > if (co) {
> > > > qemu_coroutine_enter(co);
> > > > } else {
> > > > bool done = false;
> > > > req_replayed_list_insert(reqid, &done);
> > > point B
> > > > /* wait synchronously for completion */
> > > > while (!done) {
> > > > aio_poll();
> > > > }
> > > > }
> > > > }
> > > > }
> > >
> > > One more question about coroutines.
> > > Are race conditions possible in this sample?
> > > In replay mode we may call readv, and reach point A.
> > > On the same time, we will read point B in another thread.
> > > Then readv will yield and nobody will start it back?
> >
> > There are two aspects to this:
> >
> > * Real multithreading doesn't exist in the block layer. All block driver
> > functions are only called with the mutex in the AioContext held. There
> > is exactly one AioContext per BDS, so no two threads can possible be
> > operating on the same BDS at the same time.
> >
> > * Coroutines are different from threads in that they aren't preemptive.
> > They are only interrupted in places where they explicitly yield.
> >
> > Of course, in order for this to work, we actually need to take the mutex
> > before calling blkreplay_run_event(), which is called directly from the
> > replay code (which runs in the mainloop thread? Or vcpu?).
>
> blkreplay_run_event() is called from replay code which is protected by mutex.
> This function may be called from io and vcpu threads, because both of them
> have replay functions invocations.
Now I've encountered a situation where blkreplay_run_event is called from read coroutine:
bdrv_prwv_co -> aio_poll -> qemu_clock_get_ns -> replay_read_clock -> blkreplay_run_event
\--> bdrv_co_readv -> blkreplay_co_readv -> bdrv_co_readv(lower layer)
bdrv_co_readv inside blkreplay_co_readv can't proceed in this situation.
This is probably because aio_poll has taken the aio context?
How can I resolve this?
Pavel Dovgalyuk
next prev parent reply other threads:[~2016-02-15 9:14 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-09 5:55 [Qemu-devel] [PATCH 0/3] Deterministic replay extensions Pavel Dovgalyuk
2016-02-09 5:55 ` [Qemu-devel] [PATCH 1/3] replay: character devices Pavel Dovgalyuk
2016-02-09 5:55 ` [Qemu-devel] [PATCH 2/3] replay: introduce new checkpoint for icount warp Pavel Dovgalyuk
2016-02-09 5:55 ` [Qemu-devel] [PATCH 3/3] replay: introduce block devices record/replay Pavel Dovgalyuk
2016-02-09 10:27 ` Kevin Wolf
2016-02-09 11:52 ` Pavel Dovgalyuk
2016-02-10 11:45 ` Kevin Wolf
2016-02-10 12:05 ` Pavel Dovgalyuk
2016-02-10 12:28 ` Kevin Wolf
2016-02-10 12:51 ` Pavel Dovgalyuk
2016-02-10 13:25 ` Kevin Wolf
2016-02-10 13:33 ` Pavel Dovgalyuk
2016-02-10 13:52 ` Kevin Wolf
2016-02-11 6:05 ` Pavel Dovgalyuk
2016-02-11 9:43 ` Kevin Wolf
2016-02-11 11:00 ` Pavel Dovgalyuk
2016-02-11 12:18 ` Kevin Wolf
2016-02-11 12:24 ` Pavel Dovgalyuk
2016-02-12 8:33 ` Pavel Dovgalyuk
2016-02-12 9:44 ` Kevin Wolf
2016-02-12 13:19 ` Pavel Dovgalyuk
2016-02-12 13:58 ` Kevin Wolf
2016-02-15 8:38 ` Pavel Dovgalyuk
2016-02-15 9:10 ` Kevin Wolf
2016-02-15 9:14 ` Pavel Dovgalyuk [this message]
2016-02-15 9:38 ` Kevin Wolf
2016-02-15 11:19 ` Pavel Dovgalyuk
2016-02-15 12:46 ` Kevin Wolf
2016-02-15 13:54 ` Pavel Dovgalyuk
2016-02-15 14:06 ` Kevin Wolf
2016-02-15 14:24 ` Pavel Dovgalyuk
2016-02-15 15:01 ` Kevin Wolf
2016-02-16 6:25 ` Pavel Dovgalyuk
2016-02-16 10:02 ` Kevin Wolf
2016-02-16 11:20 ` Pavel Dovgalyuk
2016-02-16 12:54 ` Kevin Wolf
2016-02-18 9:18 ` Pavel Dovgalyuk
2016-02-20 7:11 ` Pavel Dovgalyuk
2016-02-22 11:06 ` Kevin Wolf
2016-02-24 11:59 ` Pavel Dovgalyuk
2016-02-24 13:14 ` Kevin Wolf
2016-02-25 9:06 ` Pavel Dovgalyuk
2016-02-26 9:01 ` Kevin Wolf
2016-02-29 7:03 ` Pavel Dovgalyuk
2016-02-29 7:54 ` Kevin Wolf
2016-02-15 14:50 ` Pavel Dovgalyuk
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='003a01d167d1$42df95f0$c89ec1d0$@ru' \
--to=dovgaluk@ispras.ru \
--cc=alex.bennee@linaro.org \
--cc=batuzovk@ispras.ru \
--cc=edgar.iglesias@xilinx.com \
--cc=fred.konrad@greensocs.com \
--cc=hines@cert.org \
--cc=igor.rubinov@gmail.com \
--cc=kwolf@redhat.com \
--cc=maria.klimushenkova@ispras.ru \
--cc=mark.burton@greensocs.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=real@ispras.ru \
--cc=stefanha@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).