On 2011-02-16 10:57, Paolo Bonzini wrote: > On 02/16/2011 10:46 AM, Jan Kiszka wrote: >> What should this be good for? The iothread already kicks the vcpu if it >> wants to acquire the contended global mutex. > > Assuming the VCPU is in the timedwait that Marcelo changed, the global > mutex is free and the iothread will not kick the VCPU.
Then why should it kick it at all? > >> And when the vcpu thread is >> in halt state, kicking it should change no other state. > > Kicking the VCPU will start running it, if an interrupt request from the > devices caused cpu_has_work to become true (and hence > all_cpu_threads_idle to become false). If we change the halt condition, we should not kick the vcpus but only signal the condition variable. Actually, I've a patch queued that skips pointless qemu_thread_signal in qemu_cpu_kick for TCG. > > So, perhaps the correct fix is to kick the cpu in cpu_interrupt, and all > I wrote about timeouts and timers is wrong. My patch would band-aid it. That's my strong suspect. We really need to understand what goes wrong. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux