From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOUNj-0001f7-Kl for qemu-devel@nongnu.org; Mon, 01 Sep 2014 12:23:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOUNd-0008Mb-Dw for qemu-devel@nongnu.org; Mon, 01 Sep 2014 12:23:03 -0400 Received: from mail-qg0-x233.google.com ([2607:f8b0:400d:c04::233]:40510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOUNd-0008MV-8n for qemu-devel@nongnu.org; Mon, 01 Sep 2014 12:22:57 -0400 Received: by mail-qg0-f51.google.com with SMTP id i50so5454225qgf.10 for ; Mon, 01 Sep 2014 09:22:56 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <54049D5B.6040502@redhat.com> Date: Mon, 01 Sep 2014 18:22:51 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1404398025-2193-1-git-send-email-fred.konrad@greensocs.com> In-Reply-To: <1404398025-2193-1-git-send-email-fred.konrad@greensocs.com> Content-Type: text/plain; charset=windows-1252 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: fred.konrad@greensocs.com, 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 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