All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Pavel Dovgalyuk <dovgaluk@ispras.ru>,
	'Pavel Dovgalyuk' <Pavel.Dovgaluk@ispras.ru>,
	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
Subject: Re: [Qemu-devel] [PATCH v4 3/5] icount: decouple warp calls
Date: Thu, 10 Mar 2016 14:39:02 +0100	[thread overview]
Message-ID: <56E178F6.10904@redhat.com> (raw)
In-Reply-To: <000e01d17acf$7b1c3480$71549d80$@ru>



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
> 

  reply	other threads:[~2016-03-10 13:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-10 11:55 [Qemu-devel] [PATCH v4 0/5] Deterministic replay extensions Pavel Dovgalyuk
2016-03-10 11:55 ` [Qemu-devel] [PATCH v4 1/5] replay: character devices Pavel Dovgalyuk
2016-03-10 12:24   ` Paolo Bonzini
2016-03-11  6:19     ` Pavel Dovgalyuk
2016-03-11 10:06       ` Paolo Bonzini
2016-03-10 11:56 ` [Qemu-devel] [PATCH v4 2/5] icount: remove obsolete warp call Pavel Dovgalyuk
2016-03-10 12:11   ` Paolo Bonzini
2016-03-10 11:56 ` [Qemu-devel] [PATCH v4 3/5] icount: decouple warp calls Pavel Dovgalyuk
2016-03-10 12:10   ` Paolo Bonzini
2016-03-10 13:19     ` Pavel Dovgalyuk
2016-03-10 13:39       ` Paolo Bonzini [this message]
2016-03-10 11:56 ` [Qemu-devel] [PATCH v4 4/5] block: add flush callback Pavel Dovgalyuk
2016-03-10 11:56 ` [Qemu-devel] [PATCH v4 5/5] replay: introduce block devices record/replay Pavel Dovgalyuk
2016-03-11 13:58   ` Stefan Hajnoczi
2016-03-14  5:52     ` Pavel Dovgalyuk
2016-03-11 13:59   ` Stefan Hajnoczi
2016-03-14  5:53     ` Pavel Dovgalyuk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56E178F6.10904@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=Pavel.Dovgaluk@ispras.ru \
    --cc=alex.bennee@linaro.org \
    --cc=batuzovk@ispras.ru \
    --cc=dovgaluk@ispras.ru \
    --cc=edgar.iglesias@xilinx.com \
    --cc=fred.konrad@greensocs.com \
    --cc=hines@cert.org \
    --cc=igor.rubinov@gmail.com \
    --cc=kwolf@redhat.com \
    --cc=maria.klimushenkova@ispras.ru \
    --cc=mark.burton@greensocs.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=real@ispras.ru \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.