1. 02 Dec, 2013 1 commit
  2. 29 Jul, 2013 1 commit
  3. 24 May, 2013 1 commit
    • Stefan Hajnoczi's avatar
      coroutine: stop using AioContext in CoQueue · 02ffb504
      Stefan Hajnoczi authored
      qemu_co_queue_next(&queue) arranges that the next queued coroutine is
      run at a later point in time.  This deferred restart is useful because
      the caller may not want to transfer control yet.
      This behavior was implemented using QEMUBH in the past, which meant that
      CoQueue (and hence CoMutex and CoRwlock) had a dependency on the
      AioContext event loop.  This hidden dependency causes trouble when we
      move to a world with multiple event loops - now qemu_co_queue_next()
      needs to know which event loop to schedule the QEMUBH in.
      After pondering how to stash AioContext I realized the best solution is
      to not use AioContext at all.  This patch implements the deferred
      restart behavior purely in terms of coroutines and no longer uses
      Here is how it works:
      Each Coroutine has a wakeup queue that starts out empty.  When
      qemu_co_queue_next() is called, the next coroutine is added to our
      wakeup queue.  The wakeup queue is processed when we yield or terminate.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
  4. 15 Mar, 2013 1 commit
    • Stefan Hajnoczi's avatar
      coroutine: use AioContext for CoQueue BH · 28f08246
      Stefan Hajnoczi authored
      CoQueue uses a BH to awake coroutines that were made ready to run again
      using qemu_co_queue_next() or qemu_co_queue_restart_all().  The BH
      currently runs in the iothread AioContext and would break coroutines
      that run in a different AioContext.
      This is a slightly tricky problem because the lifetime of the BH exceeds
      that of the CoQueue.  This means coroutines can be awoken after CoQueue
      itself has been freed.  Also, there is no qemu_co_queue_destroy()
      function which we could use to handle freeing resources.
      Introducing qemu_co_queue_destroy() has a ripple effect of requiring us
      to also add qemu_co_mutex_destroy() and qemu_co_rwlock_destroy(), as
      well as updating all callers.  Avoid doing that.
      We also cannot switch from BH to GIdle function because aio_poll() does
      not dispatch GIdle functions.  (GIdle functions make memory management
      slightly easier because they free themselves.)
      Finally, I don't want to move unlock_queue and unlock_bh into
      AioContext.  That would break encapsulation - AioContext isn't supposed
      to know about CoQueue.
      This patch implements a different solution: each qemu_co_queue_next() or
      qemu_co_queue_restart_all() call creates a new BH and list of coroutines
      to wake up.  Callers tend to invoke qemu_co_queue_next() and
      qemu_co_queue_restart_all() occasionally after blocking I/O, so creating
      a new BH for each call shouldn't be massively inefficient.
      Note that this patch does not add an interface for specifying the
      AioContext.  That is left to future patches which will convert CoQueue,
      CoMutex, and CoRwlock to expose AioContext.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  5. 19 Dec, 2012 2 commits
  6. 30 Oct, 2012 1 commit
    • Paolo Bonzini's avatar
      aio: introduce AioContext, move bottom halves there · f627aab1
      Paolo Bonzini authored
      Start introducing AioContext, which will let us remove globals from
      aio.c/async.c, and introduce multiple I/O threads.
      The bottom half functions now take an additional AioContext argument.
      A bottom half is created with a specific AioContext that remains the
      same throughout the lifetime.  qemu_bh_new is just a wrapper that
      uses a global context.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  7. 05 Dec, 2011 2 commits
  8. 21 Oct, 2011 1 commit
  9. 23 Aug, 2011 1 commit
  10. 02 Aug, 2011 2 commits