From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdONu-0007Gz-9X for qemu-devel@nongnu.org; Fri, 17 May 2013 13:24:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UdONs-0007nu-So for qemu-devel@nongnu.org; Fri, 17 May 2013 13:24:02 -0400 Received: from [2001:41d0:8:2b42::1] (port=45989 helo=ns232118.ovh.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdONs-0007no-Jl for qemu-devel@nongnu.org; Fri, 17 May 2013 13:24:00 -0400 Message-ID: <519667A7.9010902@greensocs.com> Date: Fri, 17 May 2013 19:23:51 +0200 From: =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= MIME-Version: 1.0 References: <5189478C.8090405@greensocs.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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: Blue Swirl Cc: Mark Burton , qemu-devel On 09/05/2013 19:54, Blue Swirl wrote: > On Tue, May 7, 2013 at 6:27 PM, KONRAD Fr=C3=A9d=C3=A9ric > 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 wa= nt 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 cu= rrent >> 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=20 or sender?) 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=20 be achieved by moving qemu_icount to TimerState according to Paolo) - replaying two times the same thing and stopping at a specific=20 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=20 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=20 replay, seems the TB linked list is split dynamically? - this works with the next replay (reverse-stepi) but we can't stop=20 at the exact PC instruction with this method. So we will try to add an instruction counter in the CPUState and=20 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=20 of executed instruction and stop one instruction before. Maybe we can re-use icount mechanism but this might be a lot more=20 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=20 location? Or use both mechanism to get the right location? 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 b= e >> 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 instr= uction >> 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 >>