On 10/03/2016 14:19, Pavel Dovgalyuk wrote: >> From: Paolo Bonzini [mailto:pbonz...@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 <pavel.dovga...@ispras.ru> >> >> 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 >
