qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v9 00/23] Deterministic replay core


From: Pavel Dovgaluk
Subject: Re: [Qemu-devel] [RFC PATCH v9 00/23] Deterministic replay core
Date: Fri, 27 Feb 2015 12:23:49 +0300

> From: Paolo Bonzini [mailto:address@hidden On Behalf Of Paolo Bonzini
> On 18/02/2015 12:55, Pavel Dovgalyuk wrote:
> > This set of patches is related to the reverse execution and deterministic
> > replay of qemu execution. This implementation of deterministic replay can
> > be used for deterministic debugging of guest code through gdb remote
> > interface.
> >
> > These patches include only core function of the replay,
> > excluding the support for replaying serial, audio, network, and USB devices'
> > operations. Reverse debugging and monitor commands were also excluded to
> > be submitted later as separate patches.
> >
> > 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.
> >
> > Deterministic replay 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 and mouse
> >    input devices.
> >  * Supports auto-checkpointing for convenient reverse debugging.
> >
> > Usage of the record/replay:
> >  * First, record the execution, by adding the following string to the 
> > command line:
> >    '-icount shift=7,rr=record,rrfile=replay.bin -net none'.
> >    Block devices' images are not actually changed in the recording mode,
> >    because all of the changes are written to the temporary overlay file.
> >  * Then you can replay it for the multiple times by using another command
> >    line option: '-icount shift=7,rr=replay,rrfile=replay.bin -net none'
> >  * '-net none' option should also be specified if network replay patches
> >    are not applied.
> >
> > Paper with short description of deterministic replay implementation:
> > http://www.computer.org/csdl/proceedings/csmr/2012/4666/00/4666a553-abs.html
> >
> > Modifications of qemu include:
> >  * wrappers for clock and time functions to save their return values in the 
> > log
> >  * saving different asynchronous events (e.g. system shutdown) into the log
> >  * synchronization of the bottom halves execution
> >  * synchronization of the threads from thread pool
> >  * recording/replaying user input (mouse and keyboard)
> >  * adding internal events for cpu and io synchronization
> >
> > v9 changes:
> >  * Replaced fwrite/fread with putc/getc (as suggested by Paolo Bonzini)
> >  * Stopping virtual machine in case of replay file end (as suggested by 
> > Paolo Bonzini)
> >  * Removed one of the replay mutexes (as suggested by Paolo Bonzini)
> >  * Fixed RCU queue for bottom halves (as suggested by Paolo Bonzini)
> >  * Updated command line options' names (as suggested by Paolo Bonzini)
> >  * Added design document for record/replay (as suggested by Paolo Bonzini)
> >  * Simplified checkpoints for the timers
> >  * Added cloning InputEvent objects for replay (as suggested by Paolo 
> > Bonzini)
> >  * Added replay blockers instead of checking the command line (as suggested 
> > by Paolo
> Bonzini)
> >  * Some functions renaming and extracting.
> 
> I haven't yet reviewed patch 23 completely, and I have to think (a lot
> :)) more about block devices.  In the meanwhile I understand the replay
> code much better so I had some suggestions.

Do you have more comments? I'm ready to submit a new version.

> 
> In general, the handling of replay_has_unread_data / replay_data_kind is
> a bit messy.  It would be nice if you could call
> replay_fetch_data_kind() only when replay_has_unread_data == 0.  Or,
> even, remove replay_has_unread_data altogether: just call
> replay_fetch_data_kind() when you'd set it to zero.  That would simplify
> a lot the code for readers.

Fixed.

Pavel Dovgalyuk




reply via email to

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