qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v2 0/5] arm AioContext with its own timer stuff


From: liu ping fan
Subject: Re: [Qemu-devel] [RFC v2 0/5] arm AioContext with its own timer stuff
Date: Tue, 30 Jul 2013 11:35:02 +0800

On Mon, Jul 29, 2013 at 5:22 PM, Stefan Hajnoczi <address@hidden> wrote:
> On Mon, Jul 29, 2013 at 11:16:03AM +0800, Liu Ping Fan wrote:
>> summary of the model:
>>   Three qemu-wide clock source allowed in system. And each AioContext has
>> three corresponding timer list to run timer against clocksource.
>>
>> rfcv2:
>>    drop patches about alarm-timer(if timeout of poll will not satisfy, will 
>> come back to it)
>>    fix qemu_clock_enable sync problem (Thanks for Jan and Stefan)
>>    fix process=true when aio_poll run timers (Thanks for Alex)
>>
>> Liu Ping Fan (5):
>>   timer: protect timers_state with lock
>>   timer: pick out timer list info from QemuClock
>>   timer: make qemu_clock_enable sync between disable and timer's cb
>>   timer: associate three timerlists with AioContext
>>   timer: run timers on aio_poll
>>
>>  aio-posix.c          |   2 +
>>  async.c              |   9 +++
>>  cpus.c               |  26 ++++++--
>>  include/block/aio.h  |  13 ++++
>>  include/qemu/timer.h |  24 ++++++-
>>  main-loop.c          |   2 -
>>  qemu-timer.c         | 184 
>> ++++++++++++++++++++++++++++++++++++---------------
>>  7 files changed, 198 insertions(+), 62 deletions(-)
>
> The potential for overlap with Alex Bligh's series is large.  Can you
> base your patches on his v4?
>
Re-check the patches and Alex' patches can meet my need for further
step to make hpet run in dedicated thread. So I will rebase the sync
part of my patches onto his.

> It seems the difference is that you make clock sources to be available
> globally while Alex's series uses rt_clock (no synchronization
> necessary).
>
> Stefan



reply via email to

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