From: Kevin Wolf <kwolf@redhat.com>
To: Pavel Dovgalyuk <dovgaluk@ispras.ru>
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 10:38:10 +0100 [thread overview]
Message-ID: <20160215093810.GC5244@noname.str.redhat.com> (raw)
In-Reply-To: <003a01d167d1$42df95f0$c89ec1d0$@ru>
Am 15.02.2016 um 10:14 hat Pavel Dovgalyuk geschrieben:
> > 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?
First of all, I'm not sure if running replay events from
qemu_clock_get_ns() is such a great idea. This is not a function that
callers expect to change any state. If you absolutely have to do it
there instead of in the clock device emulations, maybe restricting it to
replaying clock events could make it a bit more harmless.
Anyway, what does "can't proceed" mean? The coroutine yields because
it's waiting for I/O, but it is never reentered? Or is it hanging while
trying to acquire a lock?
Calling the callbacks that reenter a yielded coroutine is generally the
job of aio_poll(). After reentering the coroutine, blkreplay_run_event()
should return back to its caller and therefore indirectly to aio_poll(),
which should drive the events. Sounds like it should be working.
Can you provide more detail about the exact place where it's hanging,
both in the coroutine and in the main "coroutine" that executes
aio_poll()?
Kevin
next prev parent reply other threads:[~2016-02-15 9:38 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
2016-02-15 9:38 ` Kevin Wolf [this message]
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=20160215093810.GC5244@noname.str.redhat.com \
--to=kwolf@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=batuzovk@ispras.ru \
--cc=dovgaluk@ispras.ru \
--cc=edgar.iglesias@xilinx.com \
--cc=fred.konrad@greensocs.com \
--cc=hines@cert.org \
--cc=igor.rubinov@gmail.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).