From: "Pavel Dovgalyuk" <dovgaluk@ispras.ru>
To: "'Alex Bennée'" <alex.bennee@linaro.org>
Cc: "'Nutaro, James J.'" <nutarojj@ornl.gov>,
mttcg@listserver.greensocs.com, pbonzini@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
Date: Tue, 14 Mar 2017 15:10:19 +0300 [thread overview]
Message-ID: <000001d29cbb$f396a800$dac3f800$@ru> (raw)
In-Reply-To: <874lyxqpl4.fsf@linaro.org>
> From: Alex Bennée [mailto:alex.bennee@linaro.org]
> > I also encountered icount problems with new MTTCG patches.
> >
> > Record/replay now cannot work, because iothread requests timers
> > without kicking the CPU. And cpu thread updates icount (that
> > are used for the clock).
>
> The interaction of kicking the vCPU while grabbing the BQL was a
> side-effect. This is now done explicitly for single-threaded emulation
> by (6546706d28):
>
> tcg: add kick timer for single-threaded vCPU emulation
This is not the same.
BQL helped in making execution deterministic - no io and timer
callbacks were performed while CPU is executing.
Now iothread and CPU thread work simultaneously and timers can't
query virtual time correctly, because (if we could query number of executed
instructions) it may have different values on different runs.
I guess you'll have to bring kicking CPU back on iothread invocation
to make execution deterministic in icount mode.
>
> > Therefore invocation of iothread uses incorrect clock and
> > all virtual timers behave incorrectly.
> >
> > Record/replay is also broken because current icount is requested
> > from iothread where current_cpu (and icount progress stored in icount_extra)
> > is unavailable.
>
> I'm working through Paolo's series now but I don't see it as
> insurmountable. The aim of keeping current_cpu set only during the
> cpu-exec loop was intentional because the system as a whole can't make
> assumptions about it always being valid.
Pavel Dovgalyuk
next prev parent reply other threads:[~2017-03-14 12:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-03 19:38 [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions Nutaro, James J.
2017-03-03 19:50 ` Frédéric Konrad
2017-03-06 13:08 ` Alex Bennée
2017-03-07 7:03 ` Pavel Dovgalyuk
2017-03-13 13:21 ` Alex Bennée
2017-03-14 12:10 ` Pavel Dovgalyuk [this message]
2017-03-14 12:15 ` Paolo Bonzini
2017-03-14 12:18 ` Pavel Dovgalyuk
2017-03-14 16:52 ` Paolo Bonzini
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='000001d29cbb$f396a800$dac3f800$@ru' \
--to=dovgaluk@ispras.ru \
--cc=alex.bennee@linaro.org \
--cc=mttcg@listserver.greensocs.com \
--cc=nutarojj@ornl.gov \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).