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

[Mark Burton]

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