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

[Pavel Dovgalyuk]

> -----Original Message-----
> 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?

"Deterministic" means that the replayed execution should run exactly
the same guest instructions in the same sequence, as in recording session.

> 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.

They are non-deterministic if we need instruction-level accuracy.
Thread switching (and therefore callbacks and BH execution) is 
non-deterministic.
In two different executions these callbacks may happen at different moments of
time (counting in number of executed instructions).
All operations with virtual devices (including memory, interrupt controller,
and disk drive controller) should happen at deterministic moments of time
to be replayable.

> 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.

Drivers cannot distinguish the requests from guest CPU and from savevm/loadvm.
First ones have to be deterministic, because they affect guest memory,
virtual disk controller, and interrupts.

> 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?

There is some information about it in docs/replay.txt and in
http://wiki.qemu.org/Features/record-replay

Pavel Dovgalyuk