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

[Paolo Bonzini <pbonzini@redhat.com>]

On 27/02/2015 10:23, Pavel Dovgaluk wrote:
>> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] 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.

23 is fine.  Block devices probably are best left as is for now.

Paolo

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