On Fri, Aug 2, 2013 at 10:43 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > On Fri, Aug 02, 2013 at 11:33:40AM +0800, liu ping fan wrote: >> On Thu, Aug 1, 2013 at 9:28 PM, Alex Bligh <a...@alex.org.uk> wrote: >> > Paolo, >> > >> > >> > --On 1 August 2013 08:19:34 -0400 Paolo Bonzini <pbonz...@redhat.com> >> > wrote: >> > >> >>> > True, qemu_event basically works only when a single thread resets it. >> >>> > But there is no race condition here because qemu_run_timers cannot be >> >>> > executed concurrently by multiple threads (like aio_poll in your >> >>> > bottom half patches). >> >>> >> >>> ... or, if rebasing on top of my patches, qemu_run_timers *can* be >> >>> executed concurrently by mulitple threads, but in respect of any given >> >>> QEMUTimerList, it will only be executed by one thread. >> >> >> >> >> >> ... so the event would be placed in QEMUTimerList, not QEMUClock. >> > >> > >> > Correct >> > >> > >> >> qemu_clock_enable then will have to visit all timer lists. That's >> >> not hard to do, >> > >> > >> > Correct, v4 of my patch does this. >> > >> > >> >> but as locks proliferate we need to have a clear >> >> policy (e.g. BQL -> clock -> timerlist). >> > >> > >> > But doesn't do the locking bit yet (Pingfan is going to do that I hope) >> > >> Seem that Stefanha had been involved in this, and sent out his patches :) > > Hi Ping Fan, > I dropped the series where I added locks to qemu-timer.c from a few > weeks ago. > > With your series rebased onto Alex's series, I think my patches are no > longer needed? > No. The active_timers list which is still touched by qemu_mod_timer_ns() needs protection between vcpu/iothread/.. I think you want to pick up your patches?
Regards, Pingfan
