On 19 May 2013, at 23:39, Rob Landley <r...@landley.net> 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
