On 01.07.2014 16:40, Frederic Konrad wrote:
Hi Pavel,
Thanks for sharing.
I'll take a look at your patch-set.
I suggest you try the icount mechanism and I think it might be
There is a problem with icount. I know it operates in two ways: counting
VCPU instructions (with TB size accuracy) and "warp"ing with respect to
host clock. The last one is necessary for interrupts, timers (and other
asynchronous events) while VCPU is halted (and other cases in which VCPU
instructions is not being executed). So, this referencing to host clock
(which is non-deterministic) make icount a source of non-determinism.
Hence, it cannot be used as deterministic timer (for synchronization of
asynchronous non-deterministic events) while playing.
interesting to
combine our work to have a complete solution and to avoid double copy
patches
(for example command lines, gdb stub and the snapshot mechanism).
I'll provides the last updates today or tomorrow.
Also do you have any git tree somewhere so it is easier for us to test it?
I recommand you to use git send-email to submit your patches so you can CC
people and the patch set won't be cutted by other patches in the mailing
list.
Thanks,
Fred
On 01/07/2014 13:17, Pavel Dovgaluk wrote:
Hi,
This set of patches is related to the reverse execution and deterministic
replay of qemu execution Our implementation of 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.
Usage of the record/replay:
* First, record the execution, by adding '-record fname=replay.bin'
to the
command line.
* Then you can replay it for the multiple times by using another
command
line option: '-replay fname=replay.bin'
* Virtual machine should have at least one virtual disk, which is
used to
store checkpoints. If you want to enable automatic checkpointing,
simply
add ',period=XX' to record options, where XX is the checkpointing
period
in seconds.
* Using of the network adapters in record/replay mode is possible with
the following command-line options:
- '-net user' (or another host adapter) in record mode
- '-net replay' in replay mode. Every host network adapter should be
replaced by 'replay' when replaying the execution.
* Reverse debugging can be used through gdb remote interface.
reverse-stepi and reverse-continue commands are supported. Other
reverse
commands should also work, because they reuse these ones.
* Monitor is extended by the following commands:
- replay_info - prints information about replay mode and current step
(number of instructions executed)
- replay_break - sets "breakpoint" at the specified instructions
count.
- replay_seek - rewinds (using the checkpoints, if possible) to the
specified step of replay log.
- replay_events - prints list of the external events like network
packet
input, or keyboard and mouse input.
Paper with short description of deterministic replay implementation:
http://www.computer.org/csdl/proceedings/csmr/2012/4666/00/4666a553-abs.html
...
Pavel Dovgalyuk
