Skip to content
Snippets Groups Projects
  1. Jun 02, 2023
    • Eric Blake's avatar
      cutils: Adjust signature of parse_uint[_full] · bd1386cc
      Eric Blake authored
      
      It's already confusing that we have two very similar functions for
      wrapping the parse of a 64-bit unsigned value, differing mainly on
      whether they permit leading '-'.  Adjust the signature of parse_uint()
      and parse_uint_full() to be like all of qemu_strto*(): put the result
      parameter last, use the same types (uint64_t and unsigned long long
      have the same width, but are not always the same type), and mark
      endptr const (this latter change only affects the rare caller of
      parse_uint).  Adjust all callers in the tree.
      
      While at it, note that since cutils.c already includes:
      
          QEMU_BUILD_BUG_ON(sizeof(int64_t) != sizeof(long long));
      
      we are guaranteed that the result of parse_uint* cannot exceed
      UINT64_MAX (or the build would have failed), so we can drop
      pre-existing dead comparisons in opts-visitor.c that were never false.
      
      Reviewed-by: default avatarHanna Czenczek <hreitz@redhat.com>
      Message-Id: <20230522190441.64278-8-eblake@redhat.com>
      [eblake: Drop dead code spotted by Markus]
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      bd1386cc
  2. May 30, 2023
  3. May 19, 2023
  4. May 10, 2023
  5. Feb 01, 2023
    • Emanuele Giuseppe Esposito's avatar
      block: Convert bdrv_is_inserted() to co_wrapper · 1e97be91
      Emanuele Giuseppe Esposito authored
      
      bdrv_is_inserted() is categorized as an I/O function, and it currently
      doesn't run in a coroutine. We should let it take a graph rdlock since
      it traverses the block nodes graph, which however is only possible in a
      coroutine.
      
      Therefore turn it into a co_wrapper to move the actual function into a
      coroutine where the lock can be taken.
      
      At the same time, add also blk_is_inserted as co_wrapper_mixed, since it
      is called in both coroutine and non-coroutine contexts.
      
      Because now this function creates a new coroutine and polls, we need to
      take the AioContext lock where it is missing, for the only reason that
      internally c_w_mixed_bdrv_rdlock calls AIO_WAIT_WHILE and it expects to
      release the AioContext lock. Once the rwlock is ultimated and placed in
      every place it needs to be, we will poll using AIO_WAIT_WHILE_UNLOCKED
      and remove the AioContext lock.
      
      Signed-off-by: default avatarEmanuele Giuseppe Esposito <eesposit@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Message-Id: <20230113204212.359076-5-kwolf@redhat.com>
      Reviewed-by: default avatarEmanuele Giuseppe Esposito <eesposit@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      1e97be91
  6. Jan 20, 2023
    • Markus Armbruster's avatar
      include/block: Untangle inclusion loops · e2c1c34f
      Markus Armbruster authored
      
      We have two inclusion loops:
      
             block/block.h
          -> block/block-global-state.h
          -> block/block-common.h
          -> block/blockjob.h
          -> block/block.h
      
             block/block.h
          -> block/block-io.h
          -> block/block-common.h
          -> block/blockjob.h
          -> block/block.h
      
      I believe these go back to Emanuele's reorganization of the block API,
      merged a few months ago in commit d7e2fe4a.
      
      Fortunately, breaking them is merely a matter of deleting unnecessary
      includes from headers, and adding them back in places where they are
      now missing.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20221221133551.3967339-2-armbru@redhat.com>
      e2c1c34f
  7. Dec 15, 2022
  8. Dec 14, 2022
    • Markus Armbruster's avatar
      qapi transaction: Elide redundant has_FOO in generated C · 238e9202
      Markus Armbruster authored
      
      The has_FOO for pointer-valued FOO are redundant, except for arrays.
      They are also a nuisance to work with.  Recent commit "qapi: Start to
      elide redundant has_FOO in generated C" provided the means to elide
      them step by step.  This is the step for qapi/transaction.json.
      
      Said commit explains the transformation in more detail.  The invariant
      violations mentioned there do not occur here.
      
      In qmp_transaction(), we can't just drop parameter @has_props, since
      it's used to track whether @props needs to be freed.  Replace it by a
      local variable.
      
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: Hanna Reitz <hreitz@redhat.com>
      Cc: qemu-block@nongnu.org
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20221104160712.3005652-27-armbru@redhat.com>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      238e9202
    • Markus Armbruster's avatar
      qapi block: Elide redundant has_FOO in generated C · 54fde4ff
      Markus Armbruster authored
      
      The has_FOO for pointer-valued FOO are redundant, except for arrays.
      They are also a nuisance to work with.  Recent commit "qapi: Start to
      elide redundant has_FOO in generated C" provided the means to elide
      them step by step.  This is the step for qapi/block*.json.
      
      Said commit explains the transformation in more detail.
      
      There is one instance of the invariant violation mentioned there:
      qcow2_signal_corruption() passes false, "" when node_name is an empty
      string.  Take care to pass NULL then.
      
      The previous two commits cleaned up two more.
      
      Additionally, helper bdrv_latency_histogram_stats() loses its output
      parameters and returns a value instead.
      
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: Hanna Reitz <hreitz@redhat.com>
      Cc: qemu-block@nongnu.org
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20221104160712.3005652-11-armbru@redhat.com>
      [Fixes for #ifndef LIBRBD_SUPPORTS_ENCRYPTION and MacOS squashed in]
      54fde4ff
  9. Dec 13, 2022
    • Markus Armbruster's avatar
      blockdev: Clean up abuse of DriveBackup member format · 04658a5b
      Markus Armbruster authored
      
      drive-backup argument @format defaults to the format of the source
      unless @mode is "existing".
      
      drive_backup_prepare() implements this by copying the source's
      @format_name to DriveBackup member @format.  It leaves @has_format
      false, violating the "has_format == !!format" invariant.  Unclean.
      Falls apart when we elide @has_format (commit after next): then QAPI
      passes @format, which is a string constant, to g_free().  iotest 056
      duly explodes.
      
      Clean it up.  Since the value stored in member @format is not actually
      used outside this function, use a local variable instead of modifying
      the QAPI object.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: Hanna Reitz <hreitz@redhat.com>
      Cc: qemu-block@nongnu.org
      Message-Id: <20221104160712.3005652-9-armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      04658a5b
  10. Oct 27, 2022
  11. Oct 07, 2022
  12. Sep 30, 2022
  13. Apr 06, 2022
  14. Mar 04, 2022
  15. Feb 11, 2022
  16. Jan 14, 2022
  17. Dec 28, 2021
  18. Dec 15, 2021
    • Markus Armbruster's avatar
      blockdev: Drop unused drive_get_next() · 95fd260f
      Markus Armbruster authored
      
      drive_get_next() is basically a bad idea.  It returns the "next" block
      backend of a certain interface type.  "Next" means bus=0,unit=N, where
      subsequent calls count N up from zero, per interface type.
      
      This lets you define unit numbers implicitly by execution order.  If the
      order changes, or new calls appear "in the middle", unit numbers change.
      ABI break.  Hard to spot in review.
      
      The previous commits eliminated all uses.  Drop the function.
      
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: Hanna Reitz <hreitz@redhat.com>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20211117163409.3587705-14-armbru@redhat.com>
      Reviewed-by: default avatarHanna Reitz <hreitz@redhat.com>
      95fd260f
  19. Oct 07, 2021
    • Hanna Reitz's avatar
      job: @force parameter for job_cancel_sync() · 4cfb3f05
      Hanna Reitz authored
      Callers should be able to specify whether they want job_cancel_sync() to
      force-cancel the job or not.
      
      In fact, almost all invocations do not care about consistency of the
      result and just want the job to terminate as soon as possible, so they
      should pass force=true.  The replication block driver is the exception,
      specifically the active commit job it runs.
      
      As for job_cancel_sync_all(), all callers want it to force-cancel all
      jobs, because that is the point of it: To cancel all remaining jobs as
      quickly as possible (generally on process termination).  So make it
      invoke job_cancel_sync() with force=true.
      
      This changes some iotest outputs, because quitting qemu while a mirror
      job is active will now lead to it being cancelled instead of completed,
      which is what we want.  (Cancelling a READY mirror job with force=false
      may take an indefinite amount of time, which we do not want when
      quitting.  If users want consistent results, they must have all jobs be
      done before they quit qemu.)
      
      Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462
      
      
      Signed-off-by: default avatarHanna Reitz <hreitz@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      Message-Id: <20211006151940.214590-6-hreitz@redhat.com>
      Signed-off-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      4cfb3f05
  20. Aug 26, 2021
  21. Jul 09, 2021
Loading