Skip to content
Snippets Groups Projects
  1. Jul 28, 2022
  2. Jun 28, 2022
  3. Jun 27, 2022
  4. Jun 15, 2022
  5. Jun 06, 2022
  6. Apr 21, 2022
  7. Apr 06, 2022
  8. Mar 04, 2022
    • Emanuele Giuseppe Esposito's avatar
      main-loop.h: introduce qemu_in_main_thread() · 6538692e
      Emanuele Giuseppe Esposito authored
      
      When invoked from the main loop, this function is the same
      as qemu_mutex_iothread_locked, and returns true if the BQL is held.
      When invoked from iothreads or tests, it returns true only
      if the current AioContext is the Main Loop.
      
      This essentially just extends qemu_mutex_iothread_locked to work
      also in unit tests or other users like storage-daemon, that run
      in the Main Loop but end up using the implementation in
      stubs/iothread-lock.c.
      
      Using qemu_mutex_iothread_locked in unit tests defaults to false
      because they use the implementation in stubs/iothread-lock,
      making all assertions added in next patches fail despite the
      AioContext is still the main loop.
      
      See the comment in the function header for more information.
      
      Signed-off-by: default avatarEmanuele Giuseppe Esposito <eesposit@redhat.com>
      Message-Id: <20220303151616.325444-2-eesposit@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      6538692e
  9. Jan 18, 2022
  10. Nov 04, 2021
  11. Nov 02, 2021
  12. Oct 14, 2021
  13. Sep 30, 2021
  14. Sep 04, 2021
  15. Aug 31, 2021
  16. Aug 26, 2021
  17. Jul 14, 2021
  18. Jul 09, 2021
  19. Jun 18, 2021
    • Paolo Bonzini's avatar
      async: the main AioContext is only "current" if under the BQL · 5f50be9b
      Paolo Bonzini authored
      
      If we want to wake up a coroutine from a worker thread, aio_co_wake()
      currently does not work.  In that scenario, aio_co_wake() calls
      aio_co_enter(), but there is no current AioContext and therefore
      qemu_get_current_aio_context() returns the main thread.  aio_co_wake()
      then attempts to call aio_context_acquire() instead of going through
      aio_co_schedule().
      
      The default case of qemu_get_current_aio_context() was added to cover
      synchronous I/O started from the vCPU thread, but the main and vCPU
      threads are quite different.  The main thread is an I/O thread itself,
      only running a more complicated event loop; the vCPU thread instead
      is essentially a worker thread that occasionally calls
      qemu_mutex_lock_iothread().  It is only in those critical sections
      that it acts as if it were the home thread of the main AioContext.
      
      Therefore, this patch detaches qemu_get_current_aio_context() from
      iothreads, which is a useless complication.  The AioContext pointer
      is stored directly in the thread-local variable, including for the
      main loop.  Worker threads (including vCPU threads) optionally behave
      as temporary home threads if they have taken the big QEMU lock,
      but if that is not the case they will always schedule coroutines
      on remote threads via aio_co_schedule().
      
      With this change, the stub qemu_mutex_iothread_locked() must be changed
      from true to false.  The previous value of true was needed because the
      main thread did not have an AioContext in the thread-local variable,
      but now it does have one.
      
      Reported-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Message-Id: <20210609122234.544153-1-pbonzini@redhat.com>
      Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      Tested-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      [eblake: tweak commit message per Vladimir's review]
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      5f50be9b
  20. Jun 15, 2021
  21. May 27, 2021
  22. May 26, 2021
  23. May 04, 2021
  24. May 02, 2021
  25. Apr 01, 2021
  26. Mar 19, 2021
  27. Mar 10, 2021
  28. Feb 16, 2021
    • Pavel Dovgalyuk's avatar
      replay: fix icount request when replaying clock access · 366a85e4
      Pavel Dovgalyuk authored
      
      Record/replay provides REPLAY_CLOCK_LOCKED macro to access
      the clock when vm_clock_seqlock is locked. This macro is
      needed because replay internals operate icount. In locked case
      replay use icount_get_raw_locked for icount request, which prevents
      excess locking which leads to deadlock. But previously only
      record code used *_locked function and replay did not.
      Therefore sometimes clock access lead to deadlocks.
      This patch fixes clock access for replay too and uses *_locked
      icount access function.
      
      Signed-off-by: default avatarPavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
      Message-Id: <161347990483.1313189.8371838968343494161.stgit@pasha-ThinkPad-X280>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      366a85e4
  29. Feb 08, 2021
  30. Jan 18, 2021
  31. Dec 15, 2020
Loading