1. 25 9月, 2014 2 次提交
    • M
      block: Keep DriveInfo alive until BlockDriverState dies · 3ae59580
      Markus Armbruster 提交于
      If the BDS's refcnt > 0, drive_del() destroys the DriveInfo, but not
      the BDS.  This can happen in three places:
      
      * Device model destruction during unplug: blockdev_auto_del()
      
      * Xen IDE unplug: pci_piix3_xen_ide_unplug()
      
      * drive_del command when no device model is attached: do_drive_del()
      
      The other callers of drive_del are on error paths where refcnt == 1.
      
      If the user somehow manages to plug in a device model using a BDS that
      has gone through drive_del(), the legacy configuration passed in
      DriveInfo doesn't reach the device model, and automatic deletion on
      unplug doesn't work.  Worse, some device models such as scsi-disk
      crash when DriveInfo doesn't exist.
      
      This is theoretical; I didn't research an actual reproducer. The problem
      was introduced when we replaced DriveInfo reference counting by BDS
      reference counting in commit a94a3fac..fa510ebf.
      
      Fix by keeping DriveInfo alive until its BDS dies.
      
      This affects qemu_drive_opts: now you can't reuse the same ID for new
      drive options until the BDS dies.  Before, you could, but since the
      code always attempts to create a BDS with the same ID next, the
      enclosing operation "create a new drive" failed anyway.  Different
      error path, same result.
      
      Unfortunately, the fix involves use of blockdev.c stuff from block.c,
      which is a layering violation.  Fortunately, my forthcoming
      BlockBackend work will get rid of it again.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      Reviewed-by: NBenoît Canet <benoit.canet@nodalink.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      3ae59580
    • M
      blockdev: Disentangle BlockDriverState and DriveInfo creation · a0f1eab1
      Markus Armbruster 提交于
      blockdev_init() mixes up BlockDriverState and DriveInfo initialization
      Finish the BlockDriverState job before starting to mess with
      DriveInfo.  Easier on the eyes.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      Reviewed-by: NBenoît Canet <benoit.canet@nodalink.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      a0f1eab1
  2. 11 9月, 2014 1 次提交
    • M
      blockdev: Refuse to drive_del something added with blockdev-add · 48f364dd
      Markus Armbruster 提交于
      For some device models, the guest can prevent unplug.  Some users need a
      way to forcibly revoke device model access to the block backend then, so
      the underlying images can be safely used for something else.
      
      drive_del lets you do that.  Unfortunately, it conflates revoking access
      with destroying the backend.
      
      Commit 9063f814 made drive_del immediately destroy the root BDS.  Nice:
      the device name becomes available for reuse immediately.  Not so nice:
      the device model's pointer to the root BDS dangles, and we're prone to
      crash when the memory gets reused.
      
      Commit d22b2f41 fixed that by hiding the root BDS instead of destroying
      it.  Destruction only happens on unplug.  "Hiding" means removing it
      from bdrv_states and graph_bdrv_states; see bdrv_make_anon().
      
      This "destroy on revoke" is a misfeature we don't want to carry
      forward to blockdev-add, just like "destroy on unplug" (commit
      2d246f01).  So make drive_del fail on anything added with blockdev-add.
      
      We'll add separate QMP commands to revoke device model access and to
      destroy backends.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      48f364dd
  3. 08 9月, 2014 1 次提交
  4. 29 8月, 2014 2 次提交
  5. 20 8月, 2014 2 次提交
    • S
      block: acquire AioContext in qmp_block_resize() · 927e0e76
      Stefan Hajnoczi 提交于
      Make block_resize safe for dataplane where another thread may be running
      the BlockDriverState's AioContext.
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      927e0e76
    • M
      block: Use g_new() & friends where that makes obvious sense · 5839e53b
      Markus Armbruster 提交于
      g_new(T, n) is neater than g_malloc(sizeof(T) * n).  It's also safer,
      for two reasons.  One, it catches multiplication overflowing size_t.
      Two, it returns T * rather than void *, which lets the compiler catch
      more type errors.
      
      Patch created with Coccinelle, with two manual changes on top:
      
      * Add const to bdrv_iterate_format() to keep the types straight
      
      * Convert the allocation in bdrv_drop_intermediate(), which Coccinelle
        inexplicably misses
      
      Coccinelle semantic patch:
      
          @@
          type T;
          @@
          -g_malloc(sizeof(T))
          +g_new(T, 1)
          @@
          type T;
          @@
          -g_try_malloc(sizeof(T))
          +g_try_new(T, 1)
          @@
          type T;
          @@
          -g_malloc0(sizeof(T))
          +g_new0(T, 1)
          @@
          type T;
          @@
          -g_try_malloc0(sizeof(T))
          +g_try_new0(T, 1)
          @@
          type T;
          expression n;
          @@
          -g_malloc(sizeof(T) * (n))
          +g_new(T, n)
          @@
          type T;
          expression n;
          @@
          -g_try_malloc(sizeof(T) * (n))
          +g_try_new(T, n)
          @@
          type T;
          expression n;
          @@
          -g_malloc0(sizeof(T) * (n))
          +g_new0(T, n)
          @@
          type T;
          expression n;
          @@
          -g_try_malloc0(sizeof(T) * (n))
          +g_try_new0(T, n)
          @@
          type T;
          expression p, n;
          @@
          -g_realloc(p, sizeof(T) * (n))
          +g_renew(T, p, n)
          @@
          type T;
          expression p, n;
          @@
          -g_try_realloc(p, sizeof(T) * (n))
          +g_try_renew(T, p, n)
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      Reviewed-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      5839e53b
  6. 01 7月, 2014 4 次提交
    • J
      block: add backing-file option to block-stream · 13d8cc51
      Jeff Cody 提交于
      On some image chains, QEMU may not always be able to resolve the
      filenames properly, when updating the backing file of an image
      after a block job.
      
      For instance, certain relative pathnames may fail, or drives may
      have been specified originally by file descriptor (e.g. /dev/fd/???),
      or a relative protocol pathname may have been used.
      
      In these instances, QEMU may lack the information to be able to make
      the correct choice, but the user or management layer most likely does
      have that knowledge.
      
      With this extension to the block-stream api, the user is able to change
      the backing file of the active layer as part of the block-stream
      operation.
      
      This allows the change to be 'safe', in the sense that if the attempt
      to write the active image metadata fails, then the block-stream
      operation returns failure, without disrupting the guest.
      
      If a backing file string is not specified in the command, the backing
      file string to use is determined in the same manner as it was
      previously.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      13d8cc51
    • J
      block: extend block-commit to accept a string for the backing file · 54e26900
      Jeff Cody 提交于
      On some image chains, QEMU may not always be able to resolve the
      filenames properly, when updating the backing file of an image
      after a block commit.
      
      For instance, certain relative pathnames may fail, or drives may
      have been specified originally by file descriptor (e.g. /dev/fd/???),
      or a relative protocol pathname may have been used.
      
      In these instances, QEMU may lack the information to be able to make
      the correct choice, but the user or management layer most likely does
      have that knowledge.
      
      With this extension to the block-commit api, the user is able to change
      the backing file of the overlay image as part of the block-commit
      operation.
      
      This allows the change to be 'safe', in the sense that if the attempt
      to write the overlay image metadata fails, then the block-commit
      operation returns failure, without disrupting the guest.
      
      If the commit top is the active layer, then specifying the backing
      file string will be treated as an error (there is no overlay image
      to modify in that case).
      
      If a backing file string is not specified in the command, the backing
      file string to use is determined in the same manner as it was
      previously.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Reviewed-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      54e26900
    • J
      block: add QAPI command to allow live backing file change · fa40e656
      Jeff Cody 提交于
      This allows a user to make a live change to the backing file recorded in
      an open image.
      
      The image file to modify can be specified 2 ways:
      
      1) image filename
      2) image node-name
      
      Note: this does not cause the backing file itself to be reopened; it
      merely changes the backing filename in the image file structure, and
      in internal BDS structures.
      
      It is the responsibility of the user to pass a filename string that
      can be resolved when the image chain is reopened, and the filename
      string is not validated.
      
      A good analogy for this command is that it is a live version of
      'qemu-img rebase -u', with respect to changing the backing file string.
      
      [Jeff is offline so I respun this patch in his absence.  Dropped image
      filename since using node-name is preferred and this is a new command.
      No need to introduce the limitations of finding images by filename.
      --Stefan]
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      fa40e656
    • J
      block: make 'top' argument to block-commit optional · 7676e2c5
      Jeff Cody 提交于
      Now that active layer block-commit is supported, the 'top' argument
      no longer needs to be mandatory.
      
      Change it to optional, with the default being the active layer in the
      device chain.
      
      [kwolf: Rebased and resolved conflict in tests/qemu-iotests/040]
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NBenoit Canet <benoit@irqsave.net>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      7676e2c5
  7. 28 6月, 2014 1 次提交
  8. 27 6月, 2014 2 次提交
  9. 23 6月, 2014 1 次提交
  10. 16 6月, 2014 3 次提交
  11. 04 6月, 2014 1 次提交
  12. 30 5月, 2014 2 次提交
  13. 28 5月, 2014 4 次提交
  14. 19 5月, 2014 2 次提交
    • P
      block: optimize zero writes with bdrv_write_zeroes · 465bee1d
      Peter Lieven 提交于
      this patch tries to optimize zero write requests
      by automatically using bdrv_write_zeroes if it is
      supported by the format.
      
      This significantly speeds up file system initialization and
      should speed zero write test used to test backend storage
      performance.
      
      I ran the following 2 tests on my internal SSD with a
      50G QCOW2 container and on an attached iSCSI storage.
      
      a) mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/vdX
      
      QCOW2         [off]     [on]     [unmap]
      -----
      runtime:       14secs    1.1secs  1.1secs
      filesize:      937M      18M      18M
      
      iSCSI         [off]     [on]     [unmap]
      ----
      runtime:       9.3s      0.9s     0.9s
      
      b) dd if=/dev/zero of=/dev/vdX bs=1M oflag=direct
      
      QCOW2         [off]     [on]     [unmap]
      -----
      runtime:       246secs   18secs   18secs
      filesize:      51G       192K     192K
      throughput:    203M/s    2.3G/s   2.3G/s
      
      iSCSI*        [off]     [on]     [unmap]
      ----
      runtime:       8mins     45secs   33secs
      throughput:    106M/s    1.2G/s   1.6G/s
      allocated:     100%      100%     0%
      
      * The storage was connected via an 1Gbit interface.
        It seems to internally handle writing zeroes
        via WRITESAME16 very fast.
      Signed-off-by: NPeter Lieven <pl@kamp.de>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      465bee1d
    • P
      blockdev: add a function to parse enum ids from strings · 82a402e9
      Peter Lieven 提交于
      this adds a generic function to recover the enum id of a parameter
      given as a string.
      Signed-off-by: NPeter Lieven <pl@kamp.de>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      82a402e9
  15. 26 4月, 2014 1 次提交
  16. 25 4月, 2014 1 次提交
  17. 22 4月, 2014 2 次提交
    • K
      block: Catch duplicate IDs in bdrv_new() · f2d953ec
      Kevin Wolf 提交于
      Since commit f298d071, block devices added with blockdev-add don't have
      a QemuOpts around in dinfo->opts. Consequently, we can't rely any more
      on QemuOpts catching duplicate IDs for block devices.
      
      This patch adds a new check for duplicate IDs to bdrv_new(), and moves
      the existing check that the ID isn't already taken for a node-name there
      as well.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      f2d953ec
    • K
      block: Add errp to bdrv_new() · 98522f63
      Kevin Wolf 提交于
      This patch adds an errp parameter to bdrv_new() and updates all its
      callers. The next patches will make use of this in order to check for
      duplicate IDs. Most of the callers know that their ID is fine, so they
      can simply assert that there is no error.
      
      Behaviour doesn't change with this patch yet as bdrv_new() doesn't
      actually assign errors to errp.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      98522f63
  18. 11 4月, 2014 1 次提交
  19. 07 3月, 2014 2 次提交
  20. 22 2月, 2014 2 次提交
  21. 18 2月, 2014 1 次提交
  22. 15 2月, 2014 2 次提交