1. 27 10月, 2011 3 次提交
  2. 21 10月, 2011 2 次提交
  3. 11 10月, 2011 1 次提交
    • L
      block: Keep track of devices' I/O status · 28a7282a
      Luiz Capitulino 提交于
      This commit adds support to the BlockDriverState type to keep track
      of devices' I/O status.
      
      There are three possible status: BDRV_IOS_OK (no error), BDRV_IOS_ENOSPC
      (no space error) and BDRV_IOS_FAILED (any other error). The distinction
      between no space and other errors is important because a management
      application may want to watch for no space in order to extend the
      space assigned to the VM and put it to run again.
      
      Qemu devices supporting the I/O status feature have to enable it
      explicitly by calling bdrv_iostatus_enable() _and_ have to be
      configured to stop the VM on errors (ie. werror=stop|enospc or
      rerror=stop).
      
      In case of multiple errors being triggered in sequence only the first
      one is stored. The I/O status is always reset to BDRV_IOS_OK when the
      'cont' command is issued.
      
      Next commits will add support to some devices and extend the
      query-block/info block commands to return the I/O status information.
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      28a7282a
  4. 12 9月, 2011 9 次提交
  5. 06 9月, 2011 4 次提交
  6. 27 8月, 2011 1 次提交
  7. 26 8月, 2011 1 次提交
    • C
      block: explicit I/O accounting · a597e79c
      Christoph Hellwig 提交于
      Decouple the I/O accounting from bdrv_aio_readv/writev/flush and
      make the hardware models call directly into the accounting helpers.
      
      This means:
       - we do not count internal requests from image formats in addition
         to guest originating I/O
       - we do not double count I/O ops if the device model handles it
         chunk wise
       - we only account I/O once it actuall is done
       - can extent I/O accounting to synchronous or coroutine I/O easily
       - implement I/O latency tracking easily (see the next patch)
      
      I've conveted the existing device model callers to the new model,
      device models that are using synchronous I/O and weren't accounted
      before haven't been updated yet.  Also scsi hasn't been converted
      to the end-to-end accounting as I want to defer that after the pending
      scsi layer overhaul.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      a597e79c
  8. 23 8月, 2011 1 次提交
  9. 02 8月, 2011 1 次提交
    • K
      block: Add bdrv_co_readv/writev · da1fa91d
      Kevin Wolf 提交于
      Add new block driver callbacks bdrv_co_readv/writev, which work on a
      QEMUIOVector like bdrv_aio_*, but don't need a callback. The function may only
      be called inside a coroutine, so a block driver implementing this interface can
      yield instead of blocking during I/O.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      da1fa91d
  10. 01 8月, 2011 1 次提交
  11. 19 7月, 2011 1 次提交
  12. 15 6月, 2011 1 次提交
  13. 19 5月, 2011 1 次提交
  14. 07 4月, 2011 1 次提交
    • R
      Do not delete BlockDriverState when deleting the drive · d22b2f41
      Ryan Harper 提交于
      When removing a drive from the host-side via drive_del we currently have
      the following path:
      
      drive_del
      qemu_aio_flush()
      bdrv_close()    // zaps bs->drv, which makes any subsequent I/O get
                      // dropped.  Works as designed
      drive_uninit()
      bdrv_delete()   // frees the bs.  Since the device is still connected to
                      // bs, any subsequent I/O is a use-after-free.
      
      The value of bs->drv becomes unpredictable on free.  As long as it
      remains null, I/O still gets dropped, however it could become non-null
      at any point after the free resulting SEGVs or other QEMU state
      corruption.
      
      To resolve this issue as simply as possible, we can chose to not
      actually delete the BlockDriverState pointer.  Since bdrv_close()
      handles setting the drv pointer to NULL, we just need to remove the
      BlockDriverState from the QLIST that is used to enumerate the block
      devices.  This is currently handled within bdrv_delete, so move this
      into its own function, bdrv_make_anon().
      
      The result is that we can now invoke drive_del, this closes the file
      descriptors and sets BlockDriverState->drv to NULL which prevents futher
      IO to the device, and since we do not free BlockDriverState, we don't
      have to worry about the copy retained in the block devices.
      
      We also don't attempt to remove the qdev property since we are no longer
      deleting the BlockDriverState on drives with associated drives.  This
      also allows for removing Drives with no devices associated either.
      Reported-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NRyan Harper <ryanh@us.ibm.com>
      Acked-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      d22b2f41
  15. 20 2月, 2011 1 次提交
  16. 07 2月, 2011 1 次提交
  17. 31 1月, 2011 1 次提交
  18. 17 12月, 2010 2 次提交
  19. 04 11月, 2010 1 次提交
  20. 22 10月, 2010 1 次提交
    • E
      Copy snapshots out of QCOW2 disk · 51ef6727
      edison 提交于
      In order to backup snapshots, created from QCOW2 iamge, we want to copy snapshots out of QCOW2 disk to a seperate storage.
      The following patch adds a new option in "qemu-img": qemu-img convert -f qcow2 -O qcow2 -s snapshot_name src_img bck_img.
      Right now, it only supports to copy the full snapshot, delta snapshot is on the way.
      
      Changes from V1: all the comments from Kevin are addressed:
      Add read-only checking
      Fix coding style
      Change the name from bdrv_snapshot_load to bdrv_snapshot_load_tmp
      Signed-off-by: NDisheng Su <edison@cloud.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      51ef6727
  21. 08 9月, 2010 1 次提交
    • K
      block: Fix BDRV_O_CACHE_MASK · ceb25e5c
      Kevin Wolf 提交于
      BDRV_O_CACHE_MASK should have been extended when cache=unsafe introduced a new
      flag BDRV_O_NO_FLUSH. There are currently no users that would change their
      behaviour because of this, but let's clean it up before things break.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      ceb25e5c
  22. 26 7月, 2010 1 次提交
  23. 06 7月, 2010 1 次提交
  24. 02 7月, 2010 2 次提交
    • M
      block: Fix virtual media change for if=none · 7d0d6950
      Markus Armbruster 提交于
      BlockDriverState member removable controls whether virtual media
      change (monitor commands change, eject) is allowed.  It is set when
      the "type hint" is BDRV_TYPE_CDROM or BDRV_TYPE_FLOPPY.
      
      The type hint is only set by drive_init().  It sets BDRV_TYPE_FLOPPY
      for if=floppy.  It sets BDRV_TYPE_CDROM for media=cdrom and if=ide,
      scsi, xen, or none.
      
      if=ide and if=scsi work, because the type hint makes it a CD-ROM.
      if=xen likewise, I think.
      
      For the same reason, if=none works when it's used by ide-drive or
      scsi-disk.  For other guest devices, there are problems:
      
      * fdc: you can't change virtual media
      
          $ qemu [...] -drive if=none,id=foo,... -global isa-fdc.driveA=foo
          QEMU 0.12.50 monitor - type 'help' for more information
          (qemu) eject foo
          Device 'foo' is not removable
      
        unless you add media=cdrom, but that makes it readonly.
      
      * virtio: if you add media=cdrom, you can change virtual media.  If
        you eject, the guest gets I/O errors.  If you change, the guest sees
        the drive's contents suddenly change.
      
      * scsi-generic: if you add media=cdrom, you can change virtual media.
        I didn't test what that does to the guest or the physical device,
        but it can't be pretty.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      7d0d6950
    • M
      savevm: Survive hot-unplug of snapshot device · f9092b10
      Markus Armbruster 提交于
      savevm.c keeps a pointer to the snapshot block device.  If you manage
      to get that device deleted, the pointer dangles, and the next snapshot
      operation will crash & burn.  Unplugging a guest device that uses it
      does the trick:
      
          $ MALLOC_PERTURB_=234 qemu-system-x86_64 [...]
          QEMU 0.12.50 monitor - type 'help' for more information
          (qemu) info snapshots
          No available block device supports snapshots
          (qemu) drive_add auto if=none,file=tmp.qcow2
          OK
          (qemu) device_add usb-storage,id=foo,drive=none1
          (qemu) info snapshots
          Snapshot devices: none1
          Snapshot list (from none1):
          ID        TAG                 VM SIZE                DATE       VM CLOCK
          (qemu) device_del foo
          (qemu) info snapshots
          Snapshot devices:
          Segmentation fault (core dumped)
      
      Move management of that pointer to block.c, and zap it when the device
      it points becomes unusable.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      f9092b10