qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/3] replay: introduce block devices record/repl


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 3/3] replay: introduce block devices record/replay
Date: Wed, 10 Feb 2016 12:45:31 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 09.02.2016 um 12:52 hat Pavel Dovgalyuk geschrieben:
> > From: Kevin Wolf [mailto:address@hidden
> > But even this doesn't feel completely right, because block drivers are
> > already layered and there is no need to hardcode something optional (and
> > rarely used) in the hot code path that could just be another layer.
> > 
> > I assume that you know beforehand if you want to replay something, so
> > requiring you to configure your block devices with a replay driver on
> > top of the stack seems reasonable enough.
> 
> I cannot use block drivers for this. When driver functions are used, QEMU
> is already used coroutines (and probably started bottom halves).
> Coroutines make execution non-deterministic.
> That's why we have to intercept blk_aio_ functions, that are called
> deterministically.

What does "deterministic" mean in this context, i.e. what are your exact
requirements?

I don't think that coroutines introduce anything non-deterministic per
se. Depending on what you mean by it, the block layer code paths in
block.c may contain problematic code.

The block layer uses bottom halves in some cases for request completion,
but not until calling into the first driver (why would they be a
problem?). What could happen is that a request is serialised and
therefore delayed in some special configurations, which sounds a lot
like what you wanted to avoid.

Is there a writeup somewhere of the context in which this code is called
and the rules that need to be considered for replay to work?

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]