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-requ...@listserver.greensocs.com > [mailto:mttcg-requ...@listserver.greensocs.com] > On Behalf Of Nutaro, James J. > Sent: Friday, March 03, 2017 10:39 PM > To: 'mt...@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
