From: "Pavel Dovgalyuk" <dovgaluk@ispras.ru>
To: 'Paolo Bonzini' <pbonzini@redhat.com>,
'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 v3 3/5] replay: introduce new checkpoint for icount warp
Date: Thu, 10 Mar 2016 12:10:29 +0300 [thread overview]
Message-ID: <000701d17aac$b1645040$142cf0c0$@ru> (raw)
In-Reply-To: <56E0110A.1000205@redhat.com>
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> On 01/03/2016 12:07, 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 introduces new checkpoint which distinguished warp
> > checkpoint calls from different threads.
> >
> > Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
>
> I think we need two different kinds of "warp" behavior, one to start the
> warp timer (from the main loop and when a timer is set) and one to end it
> (from the CPUs).
>
> Then the need for two checkpoints is much clearer, though I suggestnaming
> them without a reference to TCG; something like CHECKPOINT_CLOCK_WARP_START
> and CHECKPOINT_CLOCK_WARP_ACCOUNT for example.
Thanks, this seems reasonable.
> The start would be where you call qemu_clock_warp(QEMU_CLOCK_VIRTUAL, false):
>
> if (!use_icount) {
> return;
> }
> if (!runstate_is_running()) {
> return;
> }
> if (!replay_checkpoint(CHECKPOINT_CLOCK_WARP_START)) {
> return;
> }
> /* I think calling icount_warp_rt here is unnecessary. */
> if (!all_cpu_threads_idle()) {
> return;
> }
> if (qtest_enabled()) {
> /* When testing, qtest commands advance icount. */
> return;
> }
>
> /* We want to use the earliest deadline from ALL vm_clocks */
> clock = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL_RT);
> deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
> ...
>
> The end or account function, instead, would be called from tcg_exec_all()
> and also from icount_dummy_timer() (this is what makes the call to
> icount_warp_rt unnecessary above):
Why icount_warp_rt is unnecessary? There is no code to proceed the virtual clock.
Then qemu_start_warp_timer will forever setup the timer without any progress.
Pavel Dovgalyuk
next prev parent reply other threads:[~2016-03-10 9:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 11:07 [Qemu-devel] [PATCH v3 0/5] Deterministic replay extensions Pavel Dovgalyuk
2016-03-01 11:07 ` [Qemu-devel] [PATCH v3 1/5] replay: character devices Pavel Dovgalyuk
2016-03-01 11:07 ` [Qemu-devel] [PATCH v3 2/5] icount: remove obsolete warp call Pavel Dovgalyuk
2016-03-09 12:05 ` Paolo Bonzini
2016-03-01 11:07 ` [Qemu-devel] [PATCH v3 3/5] replay: introduce new checkpoint for icount warp Pavel Dovgalyuk
2016-03-09 12:03 ` Paolo Bonzini
2016-03-10 9:10 ` Pavel Dovgalyuk [this message]
2016-03-10 10:24 ` Paolo Bonzini
2016-03-01 11:07 ` [Qemu-devel] [PATCH v3 4/5] block: add flush callback Pavel Dovgalyuk
2016-03-09 11:25 ` Kevin Wolf
2016-03-01 11:08 ` [Qemu-devel] [PATCH v3 5/5] replay: introduce block devices record/replay Pavel Dovgalyuk
2016-03-09 11:43 ` Kevin Wolf
2016-03-10 6:15 ` Pavel Dovgalyuk
2016-03-07 7:21 ` [Qemu-devel] [PATCH v3 0/5] Deterministic replay extensions dovgaluk
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='000701d17aac$b1645040$142cf0c0$@ru' \
--to=dovgaluk@ispras.ru \
--cc=Pavel.Dovgaluk@ispras.ru \
--cc=alex.bennee@linaro.org \
--cc=batuzovk@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=pbonzini@redhat.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.