Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions

["Pavel Dovgalyuk" <dovgaluk@ispras.ru>]

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).

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.

Pavel Dovgalyuk

> -----Original Message-----
> From: mttcg-request@listserver.greensocs.com [mailto:mttcg-request@listserver.greensocs.com]
> On Behalf Of Nutaro, James J.
> Sent: Friday, March 03, 2017 10:39 PM
> To: 'mttcg@listserver.greensocs.com'
> Cc: 'qemu-devel@nongnu.org'
> Subject: RE: -rtc clock=vm with -icount 1,sleep=off introduces unexpected delays in device
> interactions
> 
> My original problem seems to stem from something that changed in the way that device emulation
> and instruction execution interact (I'm guessing). To reproduce the issue, I started a linux
> image with
> 
> qemu-system-i386 -rtc clock=vm -monitor none -icount 1,sleep=off jack.img
> 
> After booting, I run
> 
> ping localhost
> 
> The first round trip time reports look reasonable, being in the millisecond to sub-millisecond
> range. These occur while the emulator is running slower than real time.
> 
> After a bit, the emulator speeds up (skipping over idle periods during I/O?) and the round
> trip times jump to hundreds of milliseconds, which I had not expected.
> 
> If you want to try this experiment yourself, you can get the disk image that I used from here:
> 
> http://www.ornl.gov/~1qn/qemu-images/jack.img
> 
> 
> Jim