[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unex

From: Alex Bennée
Subject: Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
Date: Mon, 13 Mar 2017 13:21:59 +0000
User-agent: mu4e 0.9.19; emacs 25.2.9

Pavel Dovgalyuk <address@hidden> 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: address@hidden [mailto:address@hidden
>> On Behalf Of Nutaro, James J.
>> Sent: Friday, March 03, 2017 10:39 PM
>> To: 'address@hidden'
>> Cc: 'address@hidden'
>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]