1. 29 Aug, 2014 4 commits
    • Paolo Bonzini's avatar
      AioContext: introduce aio_prepare · a3462c65
      Paolo Bonzini authored
      This will be used to implement socket polling on Windows.
      On Windows, select() and g_poll() are completely different;
      sockets are polled with select() before calling g_poll,
      and the g_poll must be nonblocking if select() says a
      socket is ready.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    • Paolo Bonzini's avatar
      AioContext: export and use aio_dispatch · e4c7e2d1
      Paolo Bonzini authored
      So far, aio_poll's scheme was dispatch/poll/dispatch, where
      the first dispatch phase was used only in the GSource case in
      order to avoid a blocking poll.  Earlier patches changed it to
      dispatch/prepare/poll/dispatch, where prepare is aio_compute_timeout.
      By making aio_dispatch public, we can remove the first dispatch
      phase altogether, so that both aio_poll and the GSource use the same
      prepare/poll/dispatch scheme.
      This patch breaks the invariant that aio_poll(..., true) will not block
      the first time it returns false.  This used to be fundamental for
      qemu_aio_flush's implementation as "while (qemu_aio_wait()) {}" but
      no code in QEMU relies on this invariant anymore.  The return value
      of aio_poll() is now comparable with that of g_main_context_iteration.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    • Paolo Bonzini's avatar
      AioContext: run bottom halves after polling · 3672fa50
      Paolo Bonzini authored
      Make the dispatching phase the same before blocking and afterwards.
      The next patch will make aio_dispatch public and use it directly
      for the GSource case, instead of aio_poll.  aio_poll can then be
      simplified heavily.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    • Paolo Bonzini's avatar
      AioContext: take bottom halves into account when computing aio_poll timeout · 845ca10d
      Paolo Bonzini authored
      Right now, QEMU invokes aio_bh_poll before the "poll" phase
      of aio_poll.  It is simpler to do it afterwards and skip the
      "poll" phase altogether when the OS-dependent parts of AioContext
      are invoked from GSource.  This way, AioContext behaves more
      similarly when used as a GSource vs. when used as stand-alone.
      As a start, take bottom halves into account when computing the
      poll timeout.  If a bottom half is ready, do a non-blocking
      poll.  As a side effect, this makes idle bottom halves work
      with aio_poll; an improvement, but not really an important
      one since they are deprecated.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
  2. 09 Jul, 2014 2 commits
    • Paolo Bonzini's avatar
      AioContext: speed up aio_notify · 0ceb849b
      Paolo Bonzini authored
      In many cases, the call to event_notifier_set in aio_notify is unnecessary.
      In particular, if we are executing aio_dispatch, or if aio_poll is not
      blocking, we know that we will soon get to the next loop iteration (if
      necessary); the thread that hosts the AioContext's event loop does not
      need any nudging.
      The patch includes a Promela formal model that shows that this really
      works and does not need any further complication such as generation
      counts.  It needs a memory barrier though.
      The generation counts are not needed because any change to
      ctx->dispatching after the memory barrier is okay for aio_notify.
      If it changes from zero to one, it is the right thing to skip
      event_notifier_set.  If it changes from one to zero, the
      event_notifier_set is unnecessary but harmless.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    • Paolo Bonzini's avatar
      block: drop aio functions that operate on the main AioContext · 87f68d31
      Paolo Bonzini authored
      The main AioContext should be accessed explicitly via qemu_get_aio_context().
      Most of the time, using it is not the right thing to do.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
  3. 06 Dec, 2013 1 commit
    • Stefan Hajnoczi's avatar
      aio: make aio_poll(ctx, true) block with no fds · d3fa9230
      Stefan Hajnoczi authored
      This patch drops a special case where aio_poll(ctx, true) returns false
      instead of blocking if no file descriptors are waiting on I/O.  Now it
      is possible to block in aio_poll() to wait for aio_notify().
      This change eliminates busy waiting.  bdrv_drain_all() used to rely on
      busy waiting to completed throttled I/O requests but this is no longer
      required so we can simplify aio_poll().
      Note that aio_poll() still returns false when aio_notify() was used.  In
      other words, stopping a blocking aio_poll() wait is not considered
      making progress.
      Adjust test-aio /aio/bh/callback-delete/one which assumed aio_poll(ctx,
      true) would immediately return false instead of blocking.
      Reviewed-by: default avatarAlex Bligh <alex@alex.org.uk>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
  4. 22 Aug, 2013 1 commit
  5. 19 Aug, 2013 2 commits
    • Stefan Hajnoczi's avatar
      aio: drop io_flush argument · f2e5dca4
      Stefan Hajnoczi authored
      The .io_flush() handler no longer exists and has no users.  Drop the
      io_flush argument to aio_set_fd_handler() and related functions.
      The AioFlushEventNotifierHandler and AioFlushHandler typedefs are no
      longer used and are dropped too.
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    • Stefan Hajnoczi's avatar
      aio: stop using .io_flush() · 164a101f
      Stefan Hajnoczi authored
      Now that aio_poll() users check their termination condition themselves,
      it is no longer necessary to call .io_flush() handlers.
      The behavior of aio_poll() changes as follows:
      1. .io_flush() is no longer invoked and file descriptors are *always*
      monitored.  Previously returning 0 from .io_flush() would skip this file
      Due to this change it is essential to check that requests are pending
      before calling qemu_aio_wait().  Failure to do so means we block, for
      example, waiting for an idle iSCSI socket to become readable when there
      are no requests.  Currently all qemu_aio_wait()/aio_poll() callers check
      before calling.
      2. aio_poll() now returns true if progress was made (BH or fd handlers
      executed) and false otherwise.  Previously it would return true whenever
      'busy', which means that .io_flush() returned true.  The 'busy' concept
      no longer exists so just progress is returned.
      Due to this change we need to update tests/test-aio.c which asserts
      aio_poll() return values.  Note that QEMU doesn't actually rely on these
      return values so only tests/test-aio.c cares.
      Note that ctx->notifier, the EventNotifier fd used for aio_notify(), is
      now handled as a special case.  This is a little ugly but maintains
      aio_poll() semantics, i.e. aio_notify() does not count as 'progress' and
      aio_poll() avoids blocking when the user has not set any fd handlers yet.
      Patches after this remove .io_flush() handler code until we can finally
      drop the io_flush arguments to aio_set_fd_handler() and friends.
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
  6. 21 Feb, 2013 3 commits
  7. 17 Jan, 2013 1 commit
    • Kevin Wolf's avatar
      aio: Fix return value of aio_poll() · 2ea9b58f
      Kevin Wolf authored
      aio_poll() must return true if any work is still pending, even if it
      didn't make progress, so that bdrv_drain_all() doesn't stop waiting too
      early. The possibility of stopping early occasionally lead to a failed
      assertion in bdrv_drain_all(), when some in-flight request was missed
      and the function didn't really drain all requests.
      In order to make that change, the return value as specified in the
      function comment must change for blocking = false; fortunately, the
      return value of blocking = false callers is only used in test cases, so
      this change shouldn't cause any trouble.
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
  8. 19 Dec, 2012 2 commits
  9. 30 Oct, 2012 10 commits
  10. 28 Sep, 2012 2 commits
  11. 19 Apr, 2012 3 commits
  12. 13 Jan, 2012 1 commit
  13. 20 Aug, 2011 1 commit
  14. 21 May, 2010 1 commit
  15. 27 Oct, 2009 1 commit
  16. 12 Sep, 2009 1 commit
    • Blue Swirl's avatar
      Fix sys-queue.h conflict for good · 72cf2d4f
      Blue Swirl authored
      Problem: Our file sys-queue.h is a copy of the BSD file, but there are
      some additions and it's not entirely compatible. Because of that, there have
      been conflicts with system headers on BSD systems. Some hacks have been
      introduced in the commits 15cc9235,
      96555a96 and
      3990d09a but the fixes were fragile.
      Solution: Avoid the conflict entirely by renaming the functions and the
      file. Revert the previous hacks.
      Signed-off-by: default avatarBlue Swirl <blauwirbel@gmail.com>
  17. 22 Jul, 2009 1 commit
  18. 15 Jun, 2009 1 commit
  19. 08 May, 2009 1 commit
    • Alexander Graf's avatar
      AIO deletion race fix · 79d5ca56
      Alexander Graf authored
      When deleting an fd event there is a chance the object doesn't get
      deleted, but only ->deleted set positive and deleted somewhere later.
      Now, if we create a handler for the fd again before the actual
      deletion occurs, we end up writing data into an object that has
      ->deleted set, which is obviously wrong.
      I see two ways to fix this:
      1. Don't return ->deleted objects in the search
      2. Unset ->deleted in the search
      This patch implements 1. which feels safer to do. It fixes AIO issues
      I've seen with curl, as libcurl unsets fd event listeners pretty
      Signed-off-by: default avatarAlexander Graf <alex@csgraf.de>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  20. 05 Feb, 2009 1 commit