1. 22 Sep, 2014 1 commit
    • Chrysostomos Nanakos's avatar
      async: aio_context_new(): Handle event_notifier_init failure · 2f78e491
      Chrysostomos Nanakos authored
      On a system with a low limit of open files the initialization
      of the event notifier could fail and QEMU exits without printing any
      error information to the user.
      The problem can be easily reproduced by enforcing a low limit of open
      files and start QEMU with enough I/O threads to hit this limit.
      The same problem raises, without the creation of I/O threads, while
      QEMU initializes the main event loop by enforcing an even lower limit of
      open files.
      This commit adds an error message on failure:
       # qemu [...] -object iothread,id=iothread0 -object iothread,id=iothread1
       qemu: Failed to initialize event notifier: Too many open files in system
      Signed-off-by: default avatarChrysostomos Nanakos <cnanakos@grnet.gr>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
  2. 14 Jul, 2014 1 commit
    • Paolo Bonzini's avatar
      AioContext: do not rely on aio_poll(ctx, true) result to end a loop · acfb23ad
      Paolo Bonzini authored
      Currently, whenever aio_poll(ctx, true) has completed all pending
      work it returns true *and* the next call to aio_poll(ctx, true)
      will not block.
      This invariant has its roots in qemu_aio_flush()'s implementation
      as "while (qemu_aio_wait()) {}".  However, qemu_aio_flush() does
      not exist anymore and bdrv_drain_all() is implemented differently;
      and this invariant is complicated to maintain and subtly different
      from the return value of GMainLoop's g_main_context_iteration.
      All calls to aio_poll(ctx, true) except one are guarded by a
      while() loop checking for a request to be incomplete, or a
      BlockDriverState to be idle.  The one remaining call (in
      iothread.c) uses this to delay the aio_context_release/acquire
      pair until the AioContext is quiescent, however:
      - we can do the same just by using non-blocking aio_poll,
        similar to how vl.c invokes main_loop_wait
      - it is buggy, because it does not ensure that the AioContext
        is released between an aio_notify and the next time the
        iothread goes to sleep.  This leads to hangs when stopping
        the dataplane thread.
      In the end, these semantics are a bad match for the current
      users of AioContext.  So modify that one exception in iothread.c,
      which also fixes the hangs, as well as the testcase so that
      it use the same idiom as the actual QEMU code.
      Reported-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Tested-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
  3. 04 Apr, 2014 1 commit
  4. 13 Mar, 2014 3 commits
    • Stefan Hajnoczi's avatar
      qmp: add query-iothreads command · dc3dd0d2
      Stefan Hajnoczi authored
      The "query-iothreads" command returns a list of information about
      iothreads.  See the patch for API documentation.
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    • Stefan Hajnoczi's avatar
      iothread: stash thread ID away · 88eb7c29
      Stefan Hajnoczi authored
      Keep the thread ID around so we can report it via QMP.
      There's only one problem: qemu_get_thread_id() (gettid() wrapper on
      Linux) must be called from the thread itself.  There is no way to get
      the thread ID outside the thread.
      This patch uses a condvar to wait for iothread_run() to populate the
      thread_id inside the thread.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    • Stefan Hajnoczi's avatar
      iothread: add I/O thread object · be8d8537
      Stefan Hajnoczi authored
      This is a stand-in for Michael Roth's QContext.  I expect this to be
      replaced once QContext is completed.
      The IOThread object is an AioContext event loop thread.  This patch adds
      the concept of multiple event loop threads, allowing users to define
      When SMP guests run on SMP hosts it makes sense to instantiate multiple
      IOThreads.  This spreads event loop processing across multiple cores.
      Note that additional patches are required to actually bind a device to
      an IOThread.
      [Andreas Färber <afaerber@suse.de> pointed out that the embedded parent
      object instance should be called "parent_obj" and have a newline
      afterwards.  This patch has been changed to reflect this.
      -- Stefan]
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>