qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 17:24:18 +0300	[thread overview]
Message-ID: <005501d167fc$8ed75030$ac85f090$@ru> (raw)
In-Reply-To: <20160215140635.GF5244@noname.str.redhat.com>

> From: Kevin Wolf [mailto:kwolf@redhat.com]
> > >
> > > 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.
> >
> > Only virtual clock is emulated, and host clock is read from the host
> > real time sources and therefore has to be saved into the log.
> 
> Isn't the host clock invisible to the guest anyway?

It isn't. Host clock is used by guest RTC.

> > There could be asynchronous events that occur in non-cpu threads.
> > For now these events are shutdown request and block task execution.
> > They may "hide" following clock (or another one) events. That is why
> > we process them until synchronous event (like clock, instructions
> > execution, or checkpoint) is met.
> >
> >
> > > 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?
> >
> > I've solved this problem by slightly modifying the queue.
> > I haven't yet made BlockDriverState assignment to the request ids.
> > Therefore aio_poll was temporarily replaced with usleep.
> > Now execution starts and hangs at some random moment of OS loading.
> >
> > Here is the current version of blkreplay functions:
> >
> > static int coroutine_fn blkreplay_co_readv(BlockDriverState *bs,
> >     int64_t sector_num, int nb_sectors, QEMUIOVector *qiov)
> > {
> >     uint32_t reqid = request_id++;
> >     Request *req;
> >     req = block_request_insert(reqid, bs, qemu_coroutine_self());
> >     bdrv_co_readv(bs->file->bs, sector_num, nb_sectors, qiov);
> >
> >     if (replay_mode == REPLAY_MODE_RECORD) {
> >         replay_save_block_event(reqid);
> >     } else {
> >         assert(replay_mode == REPLAY_MODE_PLAY);
> >         qemu_coroutine_yield();
> >     }
> >     block_request_remove(req);
> >
> >     return 0;
> > }
> >
> > void replay_run_block_event(uint32_t id)
> > {
> >     Request *req;
> >     if (replay_mode == REPLAY_MODE_PLAY) {
> >         while (!(req = block_request_find(id))) {
> >             //aio_poll(bdrv_get_aio_context(req->bs), true);
> >             usleep(1);
> >         }
> 
> How is this loop supposed to make any progress?

This loop does not supposed to make any progress. It waits until block_request_insert
call is added to the queue.

> And I still don't understand why aio_poll() doesn't work and where it
> hangs.

aio_poll hangs if "req = block_request_insert(reqid, bs, qemu_coroutine_self());" line
is executed after bdrv_co_readv. When bdrv_co_readv yields, replay_run_block_event has no
information about pending request and cannot jump to its coroutine.
Maybe I should implement aio_poll execution there to make progress in that case?

> >         qemu_coroutine_enter(req->co, NULL);
> >     }
> > }


Pavel Dovgalyuk

  reply	other threads:[~2016-02-15 14:24 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
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 [this message]
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='005501d167fc$8ed75030$ac85f090$@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).