qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH] fix halt emulation with icount and CONFIG_IOTHR


From: Paolo Bonzini
Subject: [Qemu-devel] Re: [PATCH] fix halt emulation with icount and CONFIG_IOTHREAD (v2)
Date: Thu, 17 Feb 2011 09:27:43 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

On 02/17/2011 04:15 AM, Marcelo Tosatti wrote:
Yes, using qemu_icount_delta directly in tcg_wait_io_event timedwait
is explicit (partially the reason for confusion with my patch).

So the reasoning for the patch is:

With icount vm_timer timers expire on virtual CPU time. If a CPU halts,
you cannot expect passage of realtime to trigger vm_timers expiration.

But if a CPU is halted, all_cpu_threads_idle() will still be true even if you signal the condition variable, and you'll be looping in the while condition. That's why I say that

   while (x) {
       cond_timedwait (cond, mutex);
   }

(i.e. without checking the return value of cond_timedwait, and without polling something else upon return) is a broken idiom that can only work around missing signals/broadcasts.

So instead vm_timer expiration is converted to realtime, and used as
halt timeout.

But vm_timer timers are only used by "-icount auto", which works in my tests [*]. It is "-icount N" which is broken and unfortunately your patch does not fix it. The CRIS image on qemu.org triggers the watchdog (and if I eliminate the watchdog I see that the CPU is hung).

    [*] Actually, it works but doesn't calibrate very well.  It shows
        25 bogomips, sometimes 50, compared to 250 without iothread.

Paolo



reply via email to

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