> 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. > > 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