From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCOYR-0004VV-DG for qemu-devel@nongnu.org; Wed, 30 Jul 2014 03:44:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCOYJ-0007aa-SH for qemu-devel@nongnu.org; Wed, 30 Jul 2014 03:44:07 -0400 Received: from mail.ispras.ru ([83.149.199.45]:53090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCOYJ-0007aL-Jo for qemu-devel@nongnu.org; Wed, 30 Jul 2014 03:43:59 -0400 From: "Pavel Dovgaluk" References: <20140717110153.8352.80175.stgit@PASHA-ISP> <53D14707.7080509@redhat.com> <2596.37912172384$1406533875@news.gmane.org> <53D62210.9060903@redhat.com> In-Reply-To: <53D62210.9060903@redhat.com> Date: Wed, 30 Jul 2014 11:44:00 +0400 Message-ID: <000101cfabca$07016870$15043950$@Dovgaluk@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: ru Subject: Re: [Qemu-devel] [RFC PATCH v2 00/49] Series short description List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Paolo Bonzini' , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, mark.burton@greensocs.com, real@ispras.ru, batuzovk@ispras.ru, fred.konrad@greensocs.com > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo Bonzini > >> - patch 16 should also use subsections, and perhaps apply to all other > >> CPUs too? > > > > We implemented replay only for i386 and ARM. If we'll change other targets, it will not > > add record/replay capabilities to them, but can confuse the reviewers. > > Why are these fields only required by record/replay? No, these fields can cause non-determinism for normal execution mode too. But these changes are not related to reverse execution. I can make patches for them and submit them separately, if needed. > >> - patches 23-24-25 perhaps could try using icount, like Konrad's patch do? > > > > Using faster icount (like in Konrad's patches) is the our next aim. It obviously will > > increase the speed of recording process. But now I submitted slower, but more conservative > > version of icount which we had already tested. > > I see. > > >> - patch 27 makes sense but VIRTUAL is used to skip blinking when the VM > >> is stopped > > > > Right, this is kind of hack. I haven't found better solution yet. > > I think it's okay to use REALTIME, just add runstate_is_running() to the > "if (now >= s->cursor_blink_time)". > > That said, "every read to virtual clock is written to the > replay log" worries me a bit from the point of view of thread-safety. > Do you need to log all reads because you don't use icount? Reads can > only happen at given points if you use icount, and you could simply log > the icount value at each synchronization point. We made two implementations of virtual clock. One uses host realtime clock and thus should be written into the log. Another one uses icount and calculated in one of the replay modules (similar to regular icount implementation). This patch series contains only first implementation, because it looks more convenient: user does not have to specify icount shift value, when starting the recording or replaying. Pavel Dovgalyuk