Skip to content
Snippets Groups Projects
  1. Jan 25, 2024
  2. Jan 11, 2024
  3. Nov 28, 2023
    • Kevin Wolf's avatar
      export/vhost-user-blk: Fix consecutive drains · 411132c9
      Kevin Wolf authored
      The vhost-user-blk export implement AioContext switches in its drain
      implementation. This means that on drain_begin, it detaches the server
      from its AioContext and on drain_end, attaches it again and schedules
      the server->co_trip coroutine in the updated AioContext.
      
      However, nothing guarantees that server->co_trip is even safe to be
      scheduled. Not only is it unclear that the coroutine is actually in a
      state where it can be reentered externally without causing problems, but
      with two consecutive drains, it is possible that the scheduled coroutine
      didn't have a chance yet to run and trying to schedule an already
      scheduled coroutine a second time crashes with an assertion failure.
      
      Following the model of NBD, this commit makes the vhost-user-blk export
      shut down server->co_trip during drain so that resuming the export means
      creating and scheduling a new coroutine, which is always safe.
      
      There is one exception: If the drain call didn't poll (for example, this
      happens in the context of bdrv_graph_wrlock()), then the coroutine
      didn't have a chance to shut down. However, in this case the AioContext
      can't have changed; changing the AioContext always involves a polling
      drain. So in this case we can simply assert that the AioContext is
      unchanged and just leave the coroutine running or wake it up if it has
      yielded to wait for the AioContext to be attached again.
      
      Fixes: e1054cd4
      Fixes: https://issues.redhat.com/browse/RHEL-1708
      
      
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Message-ID: <20231127115755.22846-1-kwolf@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      411132c9
  4. Nov 15, 2023
  5. Nov 06, 2023
  6. Nov 03, 2023
  7. Oct 31, 2023
  8. Oct 20, 2023
    • Akihiko Odaki's avatar
      cutils: Fix get_relocated_path on Windows · 401766e0
      Akihiko Odaki authored
      
      get_relocated_path() did not have error handling for PathCchSkipRoot()
      because a path given to get_relocated_path() was expected to be a valid
      path containing a drive letter or UNC server/share path elements on
      Windows, but sometimes it turned out otherwise.
      
      The paths passed to get_relocated_path() are defined by macros generated
      by Meson. Meson in turn uses a prefix given by the configure script to
      generate them. For Windows, the script passes /qemu as a prefix to
      Meson by default.
      
      As documented in docs/about/build-platforms.rst, typically MSYS2 is used
      for the build system, but it is also possible to use Linux as well. When
      MSYS2 is used, its Bash variant recognizes /qemu as a MSYS2 path, and
      converts it to a Windows path, adding the MSYS2 prefix including a drive
      letter or UNC server/share path elements. Such a conversion does not
      happen on a shell on Linux however, and /qemu will be passed as is in
      the case.
      
      Implement a proper error handling of PathCchSkipRoot() in
      get_relocated_path() so that it can handle a path without a drive letter
      or UNC server/share path elements.
      
      Reported-by: default avatarStefan Weil <sw@weilnetz.de>
      Signed-off-by: default avatarAkihiko Odaki <akihiko.odaki@daynix.com>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      Message-ID: <20231005064726.6945-1-akihiko.odaki@daynix.com>
      Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      401766e0
  9. Oct 19, 2023
    • Akihiko Odaki's avatar
      cutils: Fix get_relocated_path on Windows · dfd3bb0a
      Akihiko Odaki authored
      
      get_relocated_path() did not have error handling for PathCchSkipRoot()
      because a path given to get_relocated_path() was expected to be a valid
      path containing a drive letter or UNC server/share path elements on
      Windows, but sometimes it turned out otherwise.
      
      The paths passed to get_relocated_path() are defined by macros generated
      by Meson. Meson in turn uses a prefix given by the configure script to
      generate them. For Windows, the script passes /qemu as a prefix to
      Meson by default.
      
      As documented in docs/about/build-platforms.rst, typically MSYS2 is used
      for the build system, but it is also possible to use Linux as well. When
      MSYS2 is used, its Bash variant recognizes /qemu as a MSYS2 path, and
      converts it to a Windows path, adding the MSYS2 prefix including a drive
      letter or UNC server/share path elements. Such a conversion does not
      happen on a shell on Linux however, and /qemu will be passed as is in
      the case.
      
      Implement a proper error handling of PathCchSkipRoot() in
      get_relocated_path() so that it can handle a path without a drive letter
      or UNC server/share path elements.
      
      Reported-by: default avatarStefan Weil <sw@weilnetz.de>
      Signed-off-by: default avatarAkihiko Odaki <akihiko.odaki@daynix.com>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      Message-ID: <20231005064726.6945-1-akihiko.odaki@daynix.com>
      Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      dfd3bb0a
  10. Oct 18, 2023
    • Paolo Bonzini's avatar
      meson, cutils: allow non-relocatable installs · 655e2a77
      Paolo Bonzini authored
      Say QEMU is configured with bindir = "/usr/bin" and a firmware path
      that starts with "/usr/share/qemu".  Ever since QEMU 5.2, QEMU's
      install has been relocatable: if you move qemu-system-x86_64 from
      /usr/bin to /home/username/bin, it will start looking for firmware in
      /home/username/share/qemu.  Previously, you would get a non-relocatable
      install where the moved QEMU will keep looking for firmware in
      /usr/share/qemu.
      
      Windows almost always wants relocatable installs, and in fact that
      is why QEMU 5.2 introduced relocatability in the first place.
      However, newfangled distribution mechanisms such as AppImage
      (https://docs.appimage.org/reference/best-practices.html
      
      ), and
      possibly NixOS, also dislike using at runtime the absolute paths
      that were established at build time.
      
      On POSIX systems you almost never care; if you do, your usecase
      dictates which one is desirable, so there's no single answer.
      Obviously relocatability works fine most of the time, because not many
      people have complained about QEMU's switch to relocatable install,
      and that's why until now there was no way to disable relocatability.
      
      But a non-relocatable, non-modular binary can help if you want to do
      experiments with old firmware and new QEMU or vice versa (because you
      can just upgrade/downgrade the firmware package, and use rpm2cpio or
      similar to extract the QEMU binaries outside /usr), so allow both.
      This patch allows one to build a non-relocatable install using a new
      option to configure.  Why?  Because it's not too hard, and because
      it helps the user double check the relocatability of their install.
      
      Note that the same code that handles relocation also lets you run QEMU
      from the build tree and pick e.g. firmware files from the source tree
      transparently.  Therefore that part remains active with this patch,
      even if you configure with --disable-relocatable.
      
      Suggested-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Reviewed-by: default avatarEmmanouil Pitsidianakis <manos.pitsidianakis@linaro.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      655e2a77
  11. Oct 17, 2023
  12. Oct 08, 2023
  13. Oct 07, 2023
    • Fiona Ebner's avatar
      util/log: re-allow switching away from stderr log file · f05142d5
      Fiona Ebner authored
      
      Commit 59bde213 ("util/log: do not close and reopen log files when
      flags are turned off") prevented switching away from stderr on a
      subsequent invocation of qemu_set_log_internal(). This prevented
      switching away from stderr with the 'logfile' monitor command as well
      as an invocation like
      > ./qemu-system-x86_64 -trace 'qemu_mutex_lock,file=log'
      from opening the specified log file.
      
      Fixes: 59bde213 ("util/log: do not close and reopen log files when flags are turned off")
      Signed-off-by: default avatarFiona Ebner <f.ebner@proxmox.com>
      Message-ID: <20231004124446.491481-1-f.ebner@proxmox.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f05142d5
  14. Oct 06, 2023
  15. Oct 04, 2023
  16. Oct 03, 2023
  17. Sep 29, 2023
  18. Sep 20, 2023
  19. Sep 16, 2023
  20. Sep 15, 2023
  21. Sep 08, 2023
    • Philippe Mathieu-Daudé's avatar
      util/iov: Avoid dynamic stack allocation · 522a9b94
      Philippe Mathieu-Daudé authored
      
      Use autofree heap allocation instead of variable-length array on the
      stack.
      
      The codebase has very few VLAs, and if we can get rid of them all we
      can make the compiler error on new additions.  This is a defensive
      measure against security bugs where an on-stack dynamic allocation
      isn't correctly size-checked (e.g.  CVE-2021-3527).
      
      Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Message-ID: <20230824164706.2652277-1-peter.maydell@linaro.org>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      522a9b94
    • Stefan Hajnoczi's avatar
      io: follow coroutine AioContext in qio_channel_yield() · 06e0f098
      Stefan Hajnoczi authored
      
      The ongoing QEMU multi-queue block layer effort makes it possible for multiple
      threads to process I/O in parallel. The nbd block driver is not compatible with
      the multi-queue block layer yet because QIOChannel cannot be used easily from
      coroutines running in multiple threads. This series changes the QIOChannel API
      to make that possible.
      
      In the current API, calling qio_channel_attach_aio_context() sets the
      AioContext where qio_channel_yield() installs an fd handler prior to yielding:
      
        qio_channel_attach_aio_context(ioc, my_ctx);
        ...
        qio_channel_yield(ioc); // my_ctx is used here
        ...
        qio_channel_detach_aio_context(ioc);
      
      This API design has limitations: reading and writing must be done in the same
      AioContext and moving between AioContexts involves a cumbersome sequence of API
      calls that is not suitable for doing on a per-request basis.
      
      There is no fundamental reason why a QIOChannel needs to run within the
      same AioContext every time qio_channel_yield() is called. QIOChannel
      only uses the AioContext while inside qio_channel_yield(). The rest of
      the time, QIOChannel is independent of any AioContext.
      
      In the new API, qio_channel_yield() queries the AioContext from the current
      coroutine using qemu_coroutine_get_aio_context(). There is no need to
      explicitly attach/detach AioContexts anymore and
      qio_channel_attach_aio_context() and qio_channel_detach_aio_context() are gone.
      One coroutine can read from the QIOChannel while another coroutine writes from
      a different AioContext.
      
      This API change allows the nbd block driver to use QIOChannel from any thread.
      It's important to keep in mind that the block driver already synchronizes
      QIOChannel access and ensures that two coroutines never read simultaneously or
      write simultaneously.
      
      This patch updates all users of qio_channel_attach_aio_context() to the
      new API. Most conversions are simple, but vhost-user-server requires a
      new qemu_coroutine_yield() call to quiesce the vu_client_trip()
      coroutine when not attached to any AioContext.
      
      While the API is has become simpler, there is one wart: QIOChannel has a
      special case for the iohandler AioContext (used for handlers that must not run
      in nested event loops). I didn't find an elegant way preserve that behavior, so
      I added a new API called qio_channel_set_follow_coroutine_ctx(ioc, true|false)
      for opting in to the new AioContext model. By default QIOChannel uses the
      iohandler AioHandler. Code that formerly called
      qio_channel_attach_aio_context() now calls
      qio_channel_set_follow_coroutine_ctx(ioc, true) once after the QIOChannel is
      created.
      
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Acked-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Message-ID: <20230830224802.493686-5-stefanha@redhat.com>
      [eblake: also fix migration/rdma.c]
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      06e0f098
  22. Sep 01, 2023
  23. Aug 31, 2023
  24. Aug 30, 2023
    • Stefan Hajnoczi's avatar
      aio-posix: zero out io_uring sqe user_data · 87ec6f55
      Stefan Hajnoczi authored
      
      liburing does not clear sqe->user_data. We must do it ourselves to avoid
      undefined behavior in process_cqe() when user_data is used.
      
      Note that fdmon-io_uring is currently disabled, so this is a latent bug
      that does not affect users. Let's merge this fix now to make it easier
      to enable fdmon-io_uring in the future (and I'm working on that).
      
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-ID: <20230426212639.82310-1-stefanha@redhat.com>
      87ec6f55
  25. Aug 29, 2023
Loading