From: "KONRAD Frédéric" <fred.konrad@greensocs.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Mark Burton <mark.burton@greensocs.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC] reverse execution.
Date: Fri, 17 May 2013 19:23:51 +0200 [thread overview]
Message-ID: <519667A7.9010902@greensocs.com> (raw)
In-Reply-To: <CAAu8pHswq_T6_gPpRAePdQuGAswzROnZkycakjaMgb1pGonCnA@mail.gmail.com>
On 09/05/2013 19:54, Blue Swirl wrote:
> On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
> <fred.konrad@greensocs.com> wrote:
>> Hi,
>>
>> We are trying to find a way to do reverse execution happen with QEMU.
>>
>> Actually, it is possible to debug the guest through the gdbstub, we want to
>> make the reverse execution possible with GDB as well.
>>
>> How we are trying to make that working (basically without optimisation):
>>
>> -QEMU takes regular snapshot of the VM:
>> that can be done with the save vm code without optimisation first.
>>
>> -When the VM is stopped and GDB requests a reverse-step:
>> load the last snapshot and replay to one instruction before the current
>> PC.
>>
>> There are one issue with that for now (for a basic running reverse
>> execution):
>> -How to stop one instruction before the actual PC.
> Add a special translation mode for reverse execution where the next PC
> is checked after each instruction. Alternatively, you could make
> temporary snapshots during this mode (first 1s intervals, then 0.1s
> etc) which could be used to find the location. I think this way was
> discussed briefly earlier in the list, please check the archives.
>
Hi, thanks for your answer!
I didn't find the discussion in the archive.. Do you have a clue? (Title
or sender?)
For now we tried some other things which are not working very well,
It appeared that the replay is not deterministic even with icount:
- the whole icount mechanism is not saved with save_vm (which can
be achieved by moving qemu_icount to TimerState according to Paolo)
- replaying two times the same thing and stopping at a specific
breakpoint show two differents vmclock, so replaying the
same amount of time don't work, and we abandoned this idea.
We tried to count the amount of time tcg_qemu_tb_exec exited with having
executed some TB and we stopped one before for the replay.
This is nearly working but:
- tcg_qemu_tb_exec exits a little more time during the first
replay, seems the TB linked list is split dynamically?
- this works with the next replay (reverse-stepi) but we can't stop
at the exact PC instruction with this method.
So we will try to add an instruction counter in the CPUState and
increments it after each instruction in the translation code,
which I think is approximately what you suggest.
Then when replaying the code from the snapshot, we will check the amount
of executed instruction and stop one instruction before.
Maybe we can re-use icount mechanism but this might be a lot more
complicated as it is a de-counter?
Can this be working?
Maybe we will need to trace the PC from the snapshot to the exact
location? Or use both mechanism to get the right location?
Thanks,
Fred
>> We though that using "-icount" and stop the guest a little time before the
>> actual position would give us the right behavior (We use a qemu_timer with
>> vm_clock to stop the vm at the good time), but it seems that it is not
>> deterministic, and not reproducable.
>>
>> Is that normal?
>>
>> We don't make any input during the replay, and we though that it can be
>> caused
>> by some timer interruption but "-icount" is using a virtual timer as I
>> understand?
>>
>> We have two other ideas:
>>
>> -Using TCI and count each instruction executed by the processor, then
>> stop
>> one instruction before the actual position. This seems slower.
>>
>> -Using single-step to count each instruction, then stop one instruction
>> before the actual position.
>>
>> Would that be better?
>>
>> For now we can restore the VM from the last snapshot, when we do a
>> reverse-step
>> but we can't stop at the exact position.
>>
>> Thanks,
>> Fred
>>
next prev parent reply other threads:[~2013-05-17 17:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-07 18:27 [Qemu-devel] [RFC] reverse execution KONRAD Frédéric
2013-05-09 17:54 ` Blue Swirl
2013-05-17 17:23 ` KONRAD Frédéric [this message]
2013-05-17 17:54 ` Peter Maydell
2013-05-17 19:16 ` Mark Burton
2013-05-23 1:57 ` Edgar E. Iglesias
2013-05-18 18:52 ` Blue Swirl
2013-05-22 16:14 ` KONRAD Frédéric
2013-05-19 4:37 ` Rob Landley
2013-05-19 7:21 ` Peter Maydell
2013-05-19 20:09 ` Mark Burton
2013-05-19 21:20 ` Peter Maydell
[not found] ` <CAD2=zRDphd7N5gCQeX6oVQP=HEbRRMpcwPKEVDj46DHKhgkKMw@mail.gmail.com>
2013-05-19 21:47 ` Brendan Dolan-Gavitt
2013-05-20 5:28 ` Mark Burton
2013-05-19 21:39 ` Rob Landley
2013-05-20 5:34 ` Mark Burton
2013-05-29 12:37 ` Pavel Dovgaluk
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=519667A7.9010902@greensocs.com \
--to=fred.konrad@greensocs.com \
--cc=blauwirbel@gmail.com \
--cc=mark.burton@greensocs.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).