[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] reverse execution.

From: Blue Swirl
Subject: Re: [Qemu-devel] [RFC] reverse execution.
Date: Sat, 18 May 2013 18:52:24 +0000

On Fri, May 17, 2013 at 5:23 PM, KONRAD Frédéric
<address@hidden> wrote:
> On 09/05/2013 19:54, Blue Swirl wrote:
>> On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
>> <address@hidden> 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?)

Paul Brook (long time QEMU developer) made a paper about this together
with Daniel Jacobowitz:

IIRC Paul also mentioned some techniques on the list at that time but
I couldn't find that in the archives.

Other related discussions:

Also this site contains some overview of reverse debugging:

> 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?

That should be easy, but not the fastest way.

> Or use both mechanism to get the right location?

Yes, you could load VM from previous snapshot and then use icount or
just host timer to get approximately halfway. Make a new snapshot and
then try again, starting from that snapshot. When you get close
enough, singlestep to the final instruction.

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]