From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ae0o7-0000t2-LW for qemu-devel@nongnu.org; Thu, 10 Mar 2016 08:39:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ae0o1-0004ug-OY for qemu-devel@nongnu.org; Thu, 10 Mar 2016 08:39:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ae0o1-0004uV-Gn for qemu-devel@nongnu.org; Thu, 10 Mar 2016 08:39:09 -0500 References: <20160310115551.4812.55431.stgit@PASHA-ISP> <20160310115609.4812.44986.stgit@PASHA-ISP> <56E1642A.4080407@redhat.com> <000e01d17acf$7b1c3480$71549d80$@ru> From: Paolo Bonzini Message-ID: <56E178F6.10904@redhat.com> Date: Thu, 10 Mar 2016 14:39:02 +0100 MIME-Version: 1.0 In-Reply-To: <000e01d17acf$7b1c3480$71549d80$@ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 3/5] icount: decouple warp calls List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Dovgalyuk , 'Pavel Dovgalyuk' , qemu-devel@nongnu.org Cc: edgar.iglesias@xilinx.com, peter.maydell@linaro.org, igor.rubinov@gmail.com, mark.burton@greensocs.com, real@ispras.ru, batuzovk@ispras.ru, maria.klimushenkova@ispras.ru, stefanha@redhat.com, kwolf@redhat.com, hines@cert.org, alex.bennee@linaro.org, fred.konrad@greensocs.com On 10/03/2016 14:19, Pavel Dovgalyuk wrote: >> From: Paolo Bonzini [mailto:pbonzini@redhat.com] >> On 10/03/2016 12:56, Pavel Dovgalyuk wrote: >>> qemu_clock_warp function is called to update virtual clock when CPU >>> is sleeping. This function includes replay checkpoint to make execution >>> deterministic in icount mode. >>> Record/replay module flushes async event queue at checkpoints. >>> Some of the events (e.g., block devices operations) include interaction >>> with hardware. E.g., APIC polled by block devices sets one of IRQ flags. >>> Flag to be set depends on currently executed thread (CPU or iothread). >>> Therefore in replay mode we have to process the checkpoints in the same thread >>> as they were recorded. >>> qemu_clock_warp function (and its checkpoint) may be called from different >>> thread. This patch decouples two different execution cases of this function: >>> call when CPU is sleeping from iothread and call from cpu thread to update >>> virtual clock. >>> First task is performed by qemu_start_warp_timer function. It sets warp >>> timer event to the moment of nearest pending virtual timer. >>> Second function (qemu_account_warp_timer) is called from cpu thread >>> before execution of the code. It advances virtual clock by adding the length >>> of period while CPU was sleeping. >>> >>> Signed-off-by: Pavel Dovgalyuk >> >> Lovely. :) One question, why doesn't icount_dummy_timer need a checkpoint? > > It is synchronized with CHECKPOINT_CLOCK_VIRTUAL_RT. > >> Only needs a change to the documentation: > > Ok, I'll change it. No problem, I can do it. Paolo >> >> diff --git a/docs/replay.txt b/docs/replay.txt >> index 149727e..26dfb6e 100644 >> --- a/docs/replay.txt >> +++ b/docs/replay.txt >> @@ -134,11 +134,18 @@ of time. That's why we do not process a group of timers until the >> checkpoint >> event will be read from the log. Such an event allows synchronizing CPU >> execution and timer events. >> >> -Another checkpoints application in record/replay is instruction counting >> -while the virtual machine is idle. This function (qemu_clock_warp) is called >> -from the wait loop. It changes virtual machine state and must be deterministic >> -then. That is why we added checkpoint to this function to prevent its >> -operation in replay mode when it does not correspond to record mode. >> +Two other checkpoints govern the "warping" of the virtual clock. While >> +the virtual machine is idle, the virtual clock increments at 1 ns per >> +*real time* nanosecond. This is done by setting up a timer (called the >> +warp timer) and then incrementing the virtual clock (called "warping" >> +the virtual clock) as soon as the CPUs need to go out of the idle state. >> +These actions change virtual machine state and must be deterministic. >> +Two functions are used for this purpose, and each of them creates a >> +checkpoint. qemu_start_warp_timer checks if the CPUs are idle and if so >> +starts accounting real time to virtual clock. qemu_account_warp_timer >> +is called when the CPUs get an interrupt or when a virtual clock timer >> +fires, and it warps the virtual clock by the amount of real time that >> +has passed since qemu_start_warp_timer. > > Pavel Dovgalyuk >