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

["Alex Bennée" <alex.bennee@linaro.org>]

Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:

> 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

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


--
Alex Bennée