Re: [Qemu-devel] [PATCH v4 3/5] icount: decouple warp calls

[Pavel Dovgalyuk]

> From: Paolo Bonzini [mailto:address@hidden
> 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 <address@hidden>
> 
> 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