From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UeBLl-0005Dd-Ot for qemu-devel@nongnu.org; Sun, 19 May 2013 17:41:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UeBLk-0001fI-Kw for qemu-devel@nongnu.org; Sun, 19 May 2013 17:41:05 -0400 Received: from mail-ie0-x22f.google.com ([2607:f8b0:4001:c03::22f]:48795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UeBLk-0001ef-Fq for qemu-devel@nongnu.org; Sun, 19 May 2013 17:41:04 -0400 Received: by mail-ie0-f175.google.com with SMTP id s9so12429755iec.20 for ; Sun, 19 May 2013 14:41:03 -0700 (PDT) Date: Sun, 19 May 2013 16:39:57 -0500 From: Rob Landley In-Reply-To: <019C9E6F-6C2C-4D59-BB88-974F498337EB@greensocs.com> (from mark.burton@greensocs.com on Sun May 19 15:09:14 2013) Message-Id: <1368999597.2776.0@driftwood> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] reverse execution. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Burton Cc: Blue Swirl , Peter Maydell , qemu-devel , KONRAD =?iso-8859-1?b?RnLpZOlyaWM=?= 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 =20 > intervals, > when you want to step backwards, you return to a snapshot, and then =20 > re-run > forwards to 'just before you started'. You'd have to snapshot all of memory because any of it could be used =20 for branching decisions. You'd have to snapshot the state of I/O =20 devices for the same reason. This includes serial ports and keyboards =20 and your hardware random number generator and the timer interrupt and =20 disk interrupts, all of which you have to log and replay the input =20 from, and get the timing exactly right for the interrupts they =20 generate. (It has to happen at the right spot because it's used to =20 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 =20 it changes into a (giant) ring buffer. Possibly instrument tcg to write =20 up that register every time it has to actually know it (jumps and when =20 interrupts happen). (You don't have to know "advanced to next =20 instruction". You do have to know "advanced to something other than =20 next instruction".) It'll be slow and painful, but might be possible. Then again to make it work you'd have to log not just where you went =20 but where you came _from_ so you could see that you got there and it's =20 time to jump again (interrupts again, doesn't mean it's a normal =20 departure point, could be a signal). And the problem is do you record =20 the target's idea of "from" or the translated host idea of "from"... Rob=