qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "KONRAD Frédéric" <fred.konrad@greensocs.com>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: Mark Burton <mark.burton@greensocs.com>, fred.konrad@greensocs.com
Subject: [Qemu-devel] [RFC] reverse execution.
Date: Tue, 07 May 2013 20:27:24 +0200	[thread overview]
Message-ID: <5189478C.8090405@greensocs.com> (raw)

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.

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

             reply	other threads:[~2013-05-07 18:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-07 18:27 KONRAD Frédéric [this message]
2013-05-09 17:54 ` [Qemu-devel] [RFC] reverse execution Blue Swirl
2013-05-17 17:23   ` KONRAD Frédéric
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=5189478C.8090405@greensocs.com \
    --to=fred.konrad@greensocs.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).