[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v9 00/23] Deterministic replay core
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC PATCH v9 00/23] Deterministic replay core |
Date: |
Fri, 27 Feb 2015 14:07:09 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
On 27/02/2015 10:23, Pavel Dovgaluk wrote:
>> 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.
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
>