Message ID | 56E1642A.4080407@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
> 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 <pavel.dovgaluk@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
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 <pavel.dovgaluk@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 >
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. Bottom halves -------------