From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBhvH-0005v1-3j for qemu-devel@nongnu.org; Mon, 28 Jul 2014 06:13:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBhv8-0006v4-0r for qemu-devel@nongnu.org; Mon, 28 Jul 2014 06:12:51 -0400 Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:41937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBhv7-0006uv-Q6 for qemu-devel@nongnu.org; Mon, 28 Jul 2014 06:12:41 -0400 Received: by mail-wi0-f169.google.com with SMTP id n3so4005744wiv.0 for ; Mon, 28 Jul 2014 03:12:38 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53D62210.9060903@redhat.com> Date: Mon, 28 Jul 2014 12:12:32 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20140717110153.8352.80175.stgit@PASHA-ISP> <53D14707.7080509@redhat.com> <2596.37912172384$1406533875@news.gmane.org> In-Reply-To: <2596.37912172384$1406533875@news.gmane.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Pavel Dovgaluk , 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 Il 28/07/2014 09:50, Pavel Dovgaluk ha scritto: >> - patches 2 to 13 probably should try to use subsections, so that VMs >> that do not use the devices try not to save the extra data and keep >> backwards migration compatibility (at least try to) > > Could you give me and example? > As I know, subsection is loaded when some predicate function returns true. How can I > construct such a function for integratorcp module? What kind of condition should it check? > In this module I just added missed vmstates (it does not saved/restored at all > by the master version). I tried to review the x86 ones. These are the most interesting ones, because it's the only board where we support cross-version migration. Parallel is (quite obviously) unsalvageable, and I think HPET is too. >> - 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? >> - 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. Paolo