Re: [Qemu-devel] Reverse execution and deterministic replay

[Pavel Dovgaluk]

> -----Original Message-----
> From: Frederic Konrad [mailto:address@hidden
> Sent: Friday, June 27, 2014 11:48 AM
> To: Pavel Dovgaluk
> Cc: Peter Crosthwaite; Paolo Bonzini; address@hidden Developers; Mark Burton
> Subject: Re: [Qemu-devel] Reverse execution and deterministic replay
> 
> On 27/06/2014 08:11, Peter Crosthwaite wrote:
> > Hi Pavel,
> >
> > On Fri, Jun 27, 2014 at 3:18 PM, Pavel Dovgaluk
> > <address@hidden> wrote:
> >> Hello!
> >>
> >> We want to publish set of patches related to the reverse execution and 
> >> deterministic replay
> of qemu.
> >> Our implementation of deterministic replay can be used for deterministic 
> >> and reverse
> debugging of
> >> guest code through gdb remote interface.
> >>
> >> Execution recording writes non-deterministic events log, which can be 
> >> later used for
> replaying the
> >> execution anywhere and for unlimited number of times. It also supports 
> >> checkpointing for
> faster
> >> rewinding during reverse debugging. Execution replaying reads the log and 
> >> replays all
> >> non-deterministic events including external input, hardware clocks, and 
> >> interrupts.
> >>
> >> Reverse execution has the following features:
> >>   * Deterministically replays whole system execution and all contents of 
> >> the memory,
> >>     state of the hadrware devices, clocks, and screen of the VM.
> >>   * Writes execution log into the file for latter replaying for multiple 
> >> times
> >>     on different machines.
> >>   * Supports i386, x86_64, and ARM hardware platforms.
> >>   * Performs deterministic replay of all operations with keyboard, mouse, 
> >> network adapters,
> >>     audio devices, serial interfaces, and physical USB devices connected 
> >> to the emulator.
> >>   * Provides support for gdb reverse debugging commands like reverse-step 
> >> and reverse-
> continue.
> >>   * Supports auto-checkpointing for convenient reverse debugging.
> >>   * Allows "going to the live execution" from the replay mode.
> >>
> >> Our implementation is completely tested for qemu 1.5 and is in beta state 
> >> for 2.0.50.
> >>
> >> Some details about our implementation of reverse execution can be found in 
> >> paper:
> >> http://www.computer.org/csdl/proceedings/csmr/2012/4666/00/4666a553-abs.html
> >>
> > Add relevant implementation details to the git commit messages.
> >
> >> Can anyone review our patches?
> >>
> > Fred Konrad is doing a series on reverse exe at the moment. CC. Is the
> > an independent implementation of the same thing or are you building on
> > it?
> 
> Hi,
> 
> Yes seems we are doing the same thing only we use icount as an instruction
> counter and you created a new instruction counter?

Yes, we created new instruction-accurate counter.

> This has advantage of having it working everywhere icount works but the
> disavantages of having to use icount for reverse execution.

The major disadvantage of icount is that it's updated only on TB boundaries.
When one instruction in the middle of the block uses virtual clock, it could
have different values for different divisions of the code to TB. E.g. you can
stop the execution using the debugger in the middle of the block. 
It will lead to creation of the new block starting from the next instruction
(which previously was in the middle of the TB). Reading virtual clock by this
instruction can give you different values.

> I think we can use both way so the reverse execution will works on other
> architecture the time an instruction counter is added to them.
> 
> I'm sure your patches will add to our solution and I can review your patches
> when you'll send them.
> 
> It would help if you rebase them on the patch set that is currently on
> the list:
> "[RFC PATCH v5 00/13] Reverse execution." I sent two days ago.

We do not use icount at all. We record virtual time into the replay log instead.
But we implemented an icount-like feature, which computes the values of virtual
clock and TSC using our internal instruction counter.

> 
> Thanks,
> Fred
> >
> > I suggest posting a full RFC, this looks to me just like a cover
> > letter but without a series.
> >
> > Note that we are going into hard freeze imminently so there will be
> > some delay for merge.
> >
> > Regards,
> > Peter
> >
> >> Pavel Dovgaluk
> >>
> >>
> >>


Pavel Dovgaluk