On Fri, Aug 09, 2013 at 04:35:31PM +0200, Paolo Bonzini wrote: > Il 09/08/2013 16:27, Alex Bligh ha scritto: > > Paolo, > > > >>> diff --git a/include/qemu/timer.h b/include/qemu/timer.h > >>> index 1baa0e2..3b46f60 100644 > >>> --- a/include/qemu/timer.h > >>> +++ b/include/qemu/timer.h > >>> @@ -52,8 +52,10 @@ typedef enum { > >>> > >>> typedef struct QEMUClock QEMUClock; > >>> typedef struct QEMUTimerList QEMUTimerList; > >>> +typedef QEMUTimerList *QEMUTimerListGroup[QEMU_CLOCK_MAX]; > >> > >> Please wrap this in a struct for easier future extensibility. > > > > OK > > > >> I'm not a big fan of the TimerListGroup name, but I cannot think of > >> anything better... > > > > Ditto > > > >> ... except if we get rid of TimerListGroup completely and put it in > >> AioContext. To do so, we can have _two_ AioContexts in main-loop.c. > >> One is for the block layer, the other is only used for timers. Later we > >> could move bottom halves from the first to the second, too. > > > > I don't really want to do this, or at least I don't want to do it yet. > > Partly my concern is about initialising a dummy AioContext and having > > it hang around. Partly the point is that the timer stuff is meant to > > work without any AioContexts. > > Perhaps, but do we really need it to work outside AioContexts? Using a > second AioContext for bottom halves has been mentioned for a while. It > would fix issues where a bottom half runs spuriously before QEMU starts, > just because something uses qemu_aio_wait(). Extending the same > approach to timers is natural. > > At some point Stefan was planning to add a per-BlockDriverState > AioContext. Once that is done, using two different AioContext for > "default block layer context" and "default main loop" context would be > very easily done.
The model I'm going for is that the user can configure how many event loop threads to use. Then they can bind a -drive to a specific event loop thread and it will operate in that AioContext. So it isn't quite a per-BDS AioContext model but perhaps I'll hit something which does require per-BDS AioContexts. History has shown the Paolo's ideas here tend to be a good solution, even when I initially tried another approach. Stefan