[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] reverse execution.
From: |
Mark Burton |
Subject: |
Re: [Qemu-devel] [RFC] reverse execution. |
Date: |
Mon, 20 May 2013 07:34:38 +0200 |
On 19 May 2013, at 23:39, Rob Landley <address@hidden> wrote:
> On 05/19/2013 03:09:14 PM, Mark Burton wrote:
>> Spot on Peter,
>> The (simplistic) plan is simply to take a snapshot at regular intervals,
>> when you want to step backwards, you return to a snapshot, and then re-run
>> forwards to 'just before you started'.
>
> You'd have to snapshot all of memory because any of it could be used for
> branching decisions. You'd have to
Yes. Qemu helps us there we believe.
> snapshot the state of I/O devices for the same reason.
Exactly.
> This includes serial ports and keyboards and your hardware random number
> generator and the timer interrupt and disk interrupts, all of which you have
> to log and replay the input from, and get the timing exactly right for the
> interrupts they
Yes. We are not there yet , but,
A) Icount seems to help make some of this more deterministic.
B) we can record the io queues activities, this has to be done for migration
too....(as I understand it)
But - as I say, we're not there yet...
> generate. (It has to happen at the right spot because it's used to update the
> random number pool, it can affect scheduling decisions...)
>
> Good luck with that.
>
> A horrid thing you might do is log the instruction pointer every time it
> changes into a (giant) ring buffer. Possibly instrument tcg to write up that
> register every time it has to actually know it (jumps and when interrupts
> happen). (You don't have to know "advanced to next instruction". You do have
> to know "advanced to something other than next instruction".) It'll be slow
> and painful, but might be possible.
>
Actually I don't believe this is enough - when the code accesses the device it
needs to get the right values , it's not good enough to force the processor to
a specific address...
But, maybe I misunderstand your idea?
Cheers
Mark
> Then again to make it work you'd have to log not just where you went but
> where you came _from_ so you could see that you got there and it's time to
> jump again (interrupts again, doesn't mean it's a normal departure point,
> could be a signal). And the problem is do you record the target's idea of
> "from" or the translated host idea of "from"...
>
> Rob
- Re: [Qemu-devel] [RFC] reverse execution., (continued)
- Re: [Qemu-devel] [RFC] reverse execution., Rob Landley, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Peter Maydell, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Mark Burton, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Peter Maydell, 2013/05/19
- Message not available
- Re: [Qemu-devel] [RFC] reverse execution., Brendan Dolan-Gavitt, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Mark Burton, 2013/05/20
- Re: [Qemu-devel] [RFC] reverse execution., Rob Landley, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution.,
Mark Burton <=
- Re: [Qemu-devel] [RFC] reverse execution., Pavel Dovgaluk, 2013/05/29