From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQtp1-0005tZ-65 for qemu-devel@nongnu.org; Mon, 08 Sep 2014 03:57:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XQtov-0004mz-D0 for qemu-devel@nongnu.org; Mon, 08 Sep 2014 03:57:11 -0400 Received: from greensocs.com ([178.33.234.66]:32789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQtov-0004mi-1x for qemu-devel@nongnu.org; Mon, 08 Sep 2014 03:57:05 -0400 Message-ID: <540D614C.9080801@greensocs.com> Date: Mon, 08 Sep 2014 09:57:00 +0200 From: Frederic Konrad MIME-Version: 1.0 References: <1404398025-2193-1-git-send-email-fred.konrad@greensocs.com> <54049D5B.6040502@redhat.com> In-Reply-To: <54049D5B.6040502@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v6 00/14] Reverse execution. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, quintela@redhat.com, mark.burton@greensocs.com, dgilbert@redhat.com, Pavel.Dovgaluk@ispras.ru, amit.shah@redhat.com, sebastian.tanase@openwide.fr, vilanova@ac.upc.edu On 01/09/2014 18:22, Paolo Bonzini wrote: > Il 03/07/2014 16:33, fred.konrad@greensocs.com ha scritto: >> From: KONRAD Frederic >> >> Hi everybody, >> >> This is the sixth version of this RFC (see the changes below). >> >> Those are the two first patch-set we have been worked on for reverse execution. >> >> The first part is fully reviewed except the "icount: introduce icount timer" >> patch maybe we can merge them? >> >> The first series: >> icount: put icount variables into TimerState. >> migration: migrate icount fields. >> migration: make qemu_savevm_state public. >> icount: introduce icount timer. >> icount: check for icount clock deadline when cpu loop exits. >> icount: make icount extra computed on icount clock as well. >> timer: add cpu_icount_to_ns function. >> >> are various preparation patches for reverse execution. >> >> The last patches: >> trace-events: add reverse-execution events. >> introduce reverse execution mechanism. >> gdbstub: allow reverse execution in gdb stub. >> cpu-exec: trigger a debug request when rexec stops. >> rexec: synchronize icount on the next event. >> rexec: allow to enable reverse execution. >> >> are reverse execution introduction. >> >> They can be clone at: git://git.greensocs.com/qemu_cexe.git:cexe_2_3_v6 >> >> The third series will be sent as soon as possible and have some issues with >> QEMU's thread as it use fork. >> >> This implementation of reverse execution works with instruction counting: >> >> A new clock is implemented which is icount clock. It grows each time an >> instruction is executed and is totally independant of host clock. >> >> Snapshots are taken regularly (based on icount clock) with help of migration >> code and written on the disk. >> >> When user wants to use reverse-stepi: >> * Last snapshot is reloaded. >> * A stop callback is created to be triggered at the previous instruction. >> >> This stop callback generates a debug exception so QEMU stops in debug mode. >> >> Command line: >> * rexec suboption is added to icount to enable reverse execution, it needs >> icount=N and doesn't support auto mode. >> >> About non determinism in QEMU: >> * This implementation doesn't take IO in account so any IO will cause non >> determinism and break reverse execution. >> >> * The icount warp mechanism have been disabled when reverse execution is >> enabled so the time grow differently inside the VM. >> >> Testing: >> * It has been tested on ARM without any IO such as network or asynchronous file >> access to keep the deterministic behaviour of icount. >> >> Known issues: >> * On ARM stepi seems to do some additional steps which are added to icount >> counter so reverse-stepi just after stepi is broken. >> >> * The IO replay explained above. > Hi, can you rebase and repost these patches? It would be nice to have a > discussion of the different approaches to record/replay in your patches > and Pavel's (perhaps before Pavel presents at KVM Forum). > > Paolo Hi Paolo, Sorry for the delay. I'll rebase and resend these patches this week. Thanks, Fred