From: Frederic Konrad <fred.konrad@greensocs.com>
To: Vasily Eefimov <real@ispras.ru>,
Pavel Dovgaluk <Pavel.Dovgaluk@ispras.ru>,
'QEMU Developers' <qemu-devel@nongnu.org>
Cc: 'Paolo Bonzini' <pbonzini@redhat.com>,
'Peter Crosthwaite' <peter.crosthwaite@xilinx.com>,
'Mark Burton' <mark.burton@greensocs.com>,
'Peter Maydell' <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [RFC PATCH 00/22] Reverse execution and deterministic replay
Date: Tue, 01 Jul 2014 15:26:36 +0200 [thread overview]
Message-ID: <53B2B70C.8060908@greensocs.com> (raw)
In-Reply-To: <53B2B379.8010100@ispras.ru>
On 01/07/2014 15:11, Vasily Eefimov wrote:
>
>
> 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.
True, this is right for virtual clock. That's why we built a new clock
which didn't take this warping in account but becomes deterministically
correct relative to the instruction counter.
Fred
>> 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
>>>
>>
>>
>
prev parent reply other threads:[~2014-07-01 13:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 11:17 [Qemu-devel] [RFC PATCH 00/22] Reverse execution and deterministic replay Pavel Dovgaluk
2014-07-01 12:40 ` Frederic Konrad
2014-07-01 13:11 ` Vasily Eefimov
2014-07-01 13:26 ` Frederic Konrad [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B2B70C.8060908@greensocs.com \
--to=fred.konrad@greensocs.com \
--cc=Pavel.Dovgaluk@ispras.ru \
--cc=mark.burton@greensocs.com \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=real@ispras.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.