On Tue, Jul 16, 2013 at 10:24:38PM +0100, Alex Bligh wrote: > --On 16 July 2013 18:55:15 +0200 Paolo Bonzini <pbonz...@redhat.com> wrote: > > >>What do you think? In the end I thought the schedule_bh_at stuff > >>was simpler. > > > >It is simpler, but I'm not sure it is the right API. Of course, if > >Kevin and Stefan says it is, I have no problem with that. > > For the sake of having something to comment on, I just sent v3 of this > patch to the list. This is basically a 'minimal change' version that > fixes the issue with aio_poll (I think). It passes make check.
I would prefer to stick with QEMUTimer instead of introducing an AioContext-specific concept that does something very similar. This can be done by introducing a per-AioContext QEMUClock. Legacy QEMUTimers will not run during aio_poll() because they are associated with vm_clock, host_clock, or rt_clock. Only QEMUTimers associated with this AioContext's aio_ctx_clock will run. In other words, the main loop will run vm_clock, host_clock, and rt_clock timers. The AioContext will run its aio_ctx_clock timers. A few notes about QEMUTimer and QEMUClock: * QEMUClock can be enabled/disabled. Disabled clocks suppress timer expiration until re-enabled. * QEMUClock can use an arbitrary time source, which is used to present a virtual time based on the instruction counter when icount mode is active. * QEMUTimer is associated with a QEMUClock. This allows timers that only expire when the vm_clock is enabled, for example. * Modifying a QEMUTimer uses qemu_notify_event() since it may be called from a vcpu thread while the iothread is blocked. The steps to achieving this: 1. Drop alarm timers from qemu-timer.c and calculate g_poll() timeout instead for the main loop. 2. Introduce a per-AioContext aio_ctx_clock that can be used with qemu_new_timer() to create a QEMUTimer that expires during aio_poll(). 3. Calculate g_poll() timeout for aio_ctx_clock in aio_poll(). Stefan
