Skip to content
Snippets Groups Projects
  1. Apr 06, 2022
  2. Mar 16, 2022
  3. Mar 06, 2022
  4. 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
    • Stefan Hajnoczi's avatar
      cpus: use coroutine TLS macros for iothread_locked · d5d2b15e
      Stefan Hajnoczi authored
      
      qemu_mutex_iothread_locked() may be used from coroutines. Standard
      __thread variables cannot be used by coroutines. Use the coroutine TLS
      macros instead.
      
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-Id: <20220222140150.27240-5-stefanha@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      d5d2b15e
  5. Feb 08, 2022
  6. Jan 08, 2022
  7. Jul 09, 2021
  8. Jun 14, 2021
  9. Feb 16, 2021
  10. Feb 05, 2021
  11. Dec 10, 2020
  12. Oct 21, 2020
  13. Oct 09, 2020
  14. Oct 06, 2020
    • Pavel Dovgaluk's avatar
      gdbstub: add reverse continue support in replay mode · cda38259
      Pavel Dovgaluk authored
      
      This patch adds support of the reverse continue operation for gdbstub.
      Reverse continue finds the last breakpoint that would happen in normal
      execution from the beginning to the current moment.
      Implementation of the reverse continue replays the execution twice:
      to find the breakpoints that were hit and to seek to the last breakpoint.
      Reverse continue loads the previous snapshot and tries to find the breakpoint
      since that moment. If there are no such breakpoints, it proceeds to
      the earlier snapshot, and so on. When no breakpoints or watchpoints were
      hit at all, execution stops at the beginning of the replay log.
      
      Signed-off-by: default avatarPavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
      Message-Id: <160174522930.12451.6994758004725016836.stgit@pasha-ThinkPad-X280>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      cda38259
    • Pavel Dovgaluk's avatar
      gdbstub: add reverse step support in replay mode · fda8458b
      Pavel Dovgaluk authored
      
      GDB remote protocol supports two reverse debugging commands:
      reverse step and reverse continue.
      This patch adds support of the first one to the gdbstub.
      Reverse step is intended to step one instruction in the backwards
      direction. This is not possible in regular execution.
      But replayed execution is deterministic, therefore we can load one of
      the prior snapshots and proceed to the desired step. It is equivalent
      to stepping one instruction back.
      There should be at least one snapshot preceding the debugged part of
      the replay log.
      
      Signed-off-by: default avatarPavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
      Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      
      --
      
      v4 changes:
       - inverted condition in cpu_handle_guest_debug (suggested by Alex Bennée)
      Message-Id: <160174522341.12451.1498758422543765253.stgit@pasha-ThinkPad-X280>
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      fda8458b
  15. Oct 05, 2020
  16. Sep 23, 2020
    • Stefan Hajnoczi's avatar
      qemu/atomic.h: rename atomic_ to qatomic_ · d73415a3
      Stefan Hajnoczi authored
      
      clang's C11 atomic_fetch_*() functions only take a C11 atomic type
      pointer argument. QEMU uses direct types (int, etc) and this causes a
      compiler error when a QEMU code calls these functions in a source file
      that also included <stdatomic.h> via a system header file:
      
        $ CC=clang CXX=clang++ ./configure ... && make
        ../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid)
      
      Avoid using atomic_*() names in QEMU's atomic.h since that namespace is
      used by <stdatomic.h>. Prefix QEMU's APIs with 'q' so that atomic.h
      and <stdatomic.h> can co-exist. I checked /usr/include on my machine and
      searched GitHub for existing "qatomic_" users but there seem to be none.
      
      This patch was generated using:
      
        $ git grep -h -o '\<atomic\(64\)\?_[a-z0-9_]\+' include/qemu/atomic.h | \
          sort -u >/tmp/changed_identifiers
        $ for identifier in $(</tmp/changed_identifiers); do
              sed -i "s%\<$identifier\>%q$identifier%g" \
                  $(git grep -I -l "\<$identifier\>")
          done
      
      I manually fixed line-wrap issues and misaligned rST tables.
      
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Message-Id: <20200923105646.47864-1-stefanha@redhat.com>
      d73415a3
  17. Sep 03, 2020
  18. Jul 10, 2020
  19. Jun 26, 2020
  20. Jun 16, 2020
Loading