Skip to content
Snippets Groups Projects
  1. Aug 30, 2023
  2. Aug 03, 2023
  3. Jul 27, 2023
  4. Jul 26, 2023
  5. Jul 25, 2023
    • Stefano Garzarella's avatar
      block/blkio: enable the completion eventfd · 9359c459
      Stefano Garzarella authored
      
      Until libblkio 1.3.0, virtio-blk drivers had completion eventfd
      notifications enabled from the start, but from the next releases
      this is no longer the case, so we have to explicitly enable them.
      
      In fact, the libblkio documentation says they could be disabled,
      so we should always enable them at the start if we want to be
      sure to get completion eventfd notifications:
      
          By default, the driver might not generate completion events for
          requests so it is necessary to explicitly enable the completion
          file descriptor before use:
      
          void blkioq_set_completion_fd_enabled(struct blkioq *q, bool enable);
      
      I discovered this while trying a development version of libblkio:
      the guest kernel hangs during boot, while probing the device.
      
      Fixes: fd66dbd4 ("blkio: add libblkio block driver")
      Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Message-id: 20230725103744.77343-1-sgarzare@redhat.com
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      9359c459
  6. Jul 19, 2023
    • Eric Blake's avatar
      nbd/client: Simplify cookie vs. index computation · 8cb98a72
      Eric Blake authored
      
      Our code relies on a sentinel cookie value of zero for deciding when a
      packet has been handled, as well as relying on array indices between 0
      and MAX_NBD_REQUESTS-1 for dereferencing purposes.  As long as we can
      symmetrically convert between two forms, there is no reason to go with
      the odd choice of using XOR with a random pointer, when we can instead
      simplify the mappings with a mere offset of 1.
      
      Using ((uint64_t)-1) as the sentinel instead of NULL such that the two
      macros could be entirely eliminated might also be possible, but would
      require a more careful audit to find places where we currently rely on
      zero-initialization to be interpreted as the sentinel value, so I did
      not pursue that course.
      
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      Message-ID: <20230608135653.2918540-7-eblake@redhat.com>
      [eblake: enhance commit message]
      Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
      8cb98a72
    • Eric Blake's avatar
      nbd: s/handle/cookie/ to match NBD spec · 22efd811
      Eric Blake authored
      Externally, libnbd exposed the 64-bit opaque marker for each client
      NBD packet as the "cookie", because it was less confusing when
      contrasted with 'struct nbd_handle *' holding all libnbd state.  It
      also avoids confusion between the noun 'handle' as a way to identify a
      packet and the verb 'handle' for reacting to things like signals.
      Upstream NBD changed their spec to favor the name "cookie" based on
      libnbd's recommendations[1], so we can do likewise.
      
      [1] https://github.com/NetworkBlockDevice/nbd/commit/ca4392eb2b
      
      
      
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      Message-ID: <20230608135653.2918540-6-eblake@redhat.com>
      [eblake: typo fix]
      Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
      22efd811
  7. Jul 17, 2023
    • Stefan Hajnoczi's avatar
      block/nvme: invoke blk_io_plug_call() outside q->lock · 66547f41
      Stefan Hajnoczi authored
      
      blk_io_plug_call() is invoked outside a blk_io_plug()/blk_io_unplug()
      section while opening the NVMe drive from:
      
        nvme_file_open() ->
        nvme_init() ->
        nvme_identify() ->
        nvme_admin_cmd_sync() ->
        nvme_submit_command() ->
        blk_io_plug_call()
      
      blk_io_plug_call() immediately invokes the given callback when the
      current thread is not plugged, as is the case during nvme_file_open().
      
      Unfortunately, nvme_submit_command() calls blk_io_plug_call() with
      q->lock still held:
      
          ...
          q->sq.tail = (q->sq.tail + 1) % NVME_QUEUE_SIZE;
          q->need_kick++;
          blk_io_plug_call(nvme_unplug_fn, q);
          qemu_mutex_unlock(&q->lock);
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
      
      nvme_unplug_fn() deadlocks trying to acquire q->lock because the lock is
      already acquired by the same thread. The symptom is that QEMU hangs
      during startup while opening the NVMe drive.
      
      Fix this by moving the blk_io_plug_call() outside q->lock. This is safe
      because no other thread runs code related to this queue and
      blk_io_plug_call()'s internal state is immune to thread safety issues
      since it is thread-local.
      
      Reported-by: default avatarLukáš Doktor <ldoktor@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Tested-by: default avatarLukas Doktor <ldoktor@redhat.com>
      Message-id: 20230712191628.252806-1-stefanha@redhat.com
      Fixes: f2e59000 ("block/nvme: convert to blk_io_plug_call() API")
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      66547f41
  8. Jul 04, 2023
    • Stefan Hajnoczi's avatar
      block/blkio: fix module_block.py parsing · c21eae1c
      Stefan Hajnoczi authored
      
      When QEMU is built with --enable-modules, the module_block.py script
      parses block/*.c to find block drivers that are built as modules. The
      script generates a table of block drivers called block_driver_modules[].
      This table is used for block driver module loading.
      
      The blkio.c driver uses macros to define its BlockDriver structs. This
      was done to avoid code duplication but the module_block.py script is
      unable to parse the macro. The result is that libblkio-based block
      drivers can be built as modules but will not be found at runtime.
      
      One fix is to make the module_block.py script or build system fancier so
      it can parse C macros (e.g. by parsing the preprocessed source code). I
      chose not to do this because it raises the complexity of the build,
      making future issues harder to debug.
      
      Keep things simple: use the macro to avoid duplicating BlockDriver
      function pointers but define .format_name and .protocol_name manually
      for each BlockDriver. This way the module_block.py is able to parse the
      code.
      
      Also get rid of the block driver name macros (e.g. DRIVER_IO_URING)
      because module_block.py cannot parse them either.
      
      Fixes: fd66dbd4 ("blkio: add libblkio block driver")
      Reported-by: default avatarQing Wang <qinwang@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Message-id: 20230704123436.187761-1-stefanha@redhat.com
      Cc: Stefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      c21eae1c
  9. Jun 28, 2023
  10. Jun 26, 2023
  11. Jun 20, 2023
  12. Jun 05, 2023
Loading