qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Pavel Dovgalyuk <Pavel.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, kwolf@redhat.com,
	pbonzini@redhat.com, batuzovk@ispras.ru, alex.bennee@linaro.org,
	fred.konrad@greensocs.com
Subject: Re: [Qemu-devel] [PATCH v2 4/4] replay: introduce block devices record/replay
Date: Thu, 11 Feb 2016 14:51:35 +0000	[thread overview]
Message-ID: <20160211145135.GB7285@stefanha-x1.localdomain> (raw)
In-Reply-To: <002c01d164d3$7a8b4680$6fa1d380$@Dovgaluk@ispras.ru>

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

On Thu, Feb 11, 2016 at 04:52:42PM +0300, Pavel Dovgalyuk wrote:
> > From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> > On Wed, Feb 10, 2016 at 12:13:23PM +0300, Pavel Dovgalyuk wrote:
> > > @@ -784,7 +798,11 @@ BlockAIOCB *blk_aio_flush(BlockBackend *blk,
> > >          return blk_abort_aio_request(blk, cb, opaque, -ENOMEDIUM);
> > >      }
> > >
> > > -    return bdrv_aio_flush(blk->bs, cb, opaque);
> > > +    if (replay_mode == REPLAY_MODE_NONE) {
> > > +        return bdrv_aio_flush(blk->bs, cb, opaque);
> > > +    } else {
> > > +        return replay_aio_flush(blk->bs, cb, opaque);
> > > +    }
> > >  }
> > 
> > I am only looking at this patch in isolation and am not familiar with
> > the record/replay work, but these changes appear invasive.  In order for
> > record/replay to keep working in the future, everyone touching block
> > layer code must be familiar with the principles of how record/replay
> > works.  This patch does not include documentation.
> 
> We've already discussed it with Kevin.
> He proposes adding new block driver for record/replay.
> 
> > Can you point me to documentation that explains the how record replay
> > works?
> 
> There is some information about it in docs/replay.txt and in
> http://wiki.qemu.org/Features/record-replay

I was thinking about developer documentation.  A feature like this is
"cross-cutting" - it affects many components.  There should be
documentation that explains the semantics so everyone modifying code can
follow the rules to keep record/replay working.

Live migration is similar in that it touches many components.  The
docs/migration.txt file explains the APIs and general idea.  It
communicates the assumptions, limitations, and requirements that live
migration imposes.  Many QEMU developers understand migration basics and
keep them in mind during code review.  This way we can prevent most (but
not all) migration breakage.

Record/replay should aim for the same level of education/awareness,
otherwise the feature will break and bitrot.

The alternative is to implement it in a way that isn't invasive.  Then
other developers don't need to understand how it works.  Maybe
implementing it in a block driver can achieve this.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

      reply	other threads:[~2016-02-11 14:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-10  9:13 [Qemu-devel] [PATCH v2 0/4] Deterministic replay extensions Pavel Dovgalyuk
2016-02-10  9:13 ` [Qemu-devel] [PATCH v2 1/4] replay: character devices Pavel Dovgalyuk
2016-02-10  9:13 ` [Qemu-devel] [PATCH v2 2/4] icount: remove obsolete warp call Pavel Dovgalyuk
2016-02-10  9:13 ` [Qemu-devel] [PATCH v2 3/4] replay: introduce new checkpoint for icount warp Pavel Dovgalyuk
2016-02-10  9:13 ` [Qemu-devel] [PATCH v2 4/4] replay: introduce block devices record/replay Pavel Dovgalyuk
2016-02-11  9:56   ` Stefan Hajnoczi
2016-02-11 13:52     ` Pavel Dovgalyuk
2016-02-11 14:51       ` Stefan Hajnoczi [this message]

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=20160211145135.GB7285@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=Pavel.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 \
    /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).