1. 22 Apr, 2013 2 commits
    • Kevin Wolf's avatar
      block: Add driver-specific options for backing files · 31ca6d07
      Kevin Wolf authored
      Options starting in "backing." are passed to the backing file now. If
      you don't need to specify the filename for the backing file, you can add
      it on the command line instead of in the image file:
      $ qemu-nbd -t /tmp/test.img
      $ qemu-img create -f qcow2 empty.qcow2 1G
      $ qemu-system-x86_64 -drive file=empty.qcow2,backing.file.driver=nbd,\
      Note that this doesn't override the backing filename from the image. If
      the image has one, this will fail because NBD doesn't want the options
      and a filename at the same time.
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    • Kevin Wolf's avatar
      block: Fail gracefully when using a format driver on protocol level · 2af5ef70
      Kevin Wolf authored
      Specifying the wrong driver could fail an assertion:
      $ qemu-system-x86_64 -drive file.driver=qcow2,file=x
      qemu-system-x86_64: block.c:721: bdrv_open_common: Assertion `file !=
      ((void *)0)' failed.
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
  2. 15 Apr, 2013 2 commits
  3. 05 Apr, 2013 4 commits
  4. 28 Mar, 2013 1 commit
  5. 22 Mar, 2013 6 commits
  6. 19 Mar, 2013 1 commit
  7. 15 Mar, 2013 4 commits
  8. 04 Mar, 2013 1 commit
  9. 22 Feb, 2013 4 commits
  10. 01 Feb, 2013 1 commit
  11. 25 Jan, 2013 4 commits
  12. 15 Jan, 2013 2 commits
    • Paolo Bonzini's avatar
      block: clear dirty bitmap when discarding · df702c9b
      Paolo Bonzini authored
      Note that resetting bits in the dirty bitmap is done _before_ actually
      processing the request.  Writes, instead, set bits after the request
      is completed.
      This way, when there are concurrent write and discard requests, the
      outcome will always be that the blocks are marked dirty.  This scenario
      should never happen, but it is safer to do it this way.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    • Peter Lieven's avatar
      block: fix initialization in bdrv_io_limits_enable() · 029d091e
      Peter Lieven authored
      bdrv_io_limits_enable() starts a new slice, but does not set io_base
      correctly for that slice.
      Here is how io_base is used:
          bytes_base  = bs->nr_bytes[is_write] - bs->io_base.bytes[is_write];
          bytes_res   = (unsigned) nb_sectors * BDRV_SECTOR_SIZE;
          if (bytes_base + bytes_res <= bytes_limit) {
              /* no wait */
          } else {
              /* operation needs to be throttled */
      As a result, any I/O operations that are triggered between now and
      bs->slice_end are incorrectly limited.  If 10 MB of data has been
      written since the VM was started, QEMU thinks that 10 MB of data has
      been written in this slice. This leads to a I/O lockup in the guest.
      We fix this by delaying the start of a new slice to the next
      call of bdrv_exceed_io_limits().
      Signed-off-by: default avatarPeter Lieven <pl@kamp.de>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
  13. 14 Jan, 2013 2 commits
  14. 11 Jan, 2013 1 commit
  15. 19 Dec, 2012 5 commits