1. 12 9月, 2011 7 次提交
  2. 06 9月, 2011 4 次提交
  3. 27 8月, 2011 1 次提交
  4. 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
  5. 23 8月, 2011 1 次提交
  6. 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
  7. 01 8月, 2011 1 次提交
  8. 19 7月, 2011 1 次提交
  9. 15 6月, 2011 1 次提交
  10. 19 5月, 2011 1 次提交
  11. 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
  12. 20 2月, 2011 1 次提交
  13. 07 2月, 2011 1 次提交
  14. 31 1月, 2011 1 次提交
  15. 17 12月, 2010 2 次提交
  16. 04 11月, 2010 1 次提交
  17. 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
  18. 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
  19. 26 7月, 2010 1 次提交
  20. 06 7月, 2010 1 次提交
  21. 02 7月, 2010 3 次提交
    • 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
    • M
      block: Catch attempt to attach multiple devices to a blockdev · 18846dee
      Markus Armbruster 提交于
      For instance, -device scsi-disk,drive=foo -device scsi-disk,drive=foo
      happily creates two SCSI disks connected to the same block device.
      It's all downhill from there.
      
      Device usb-storage deliberately attaches twice to the same blockdev,
      which fails with the fix in place.  Detach before the second attach
      there.
      
      Also catch attempt to delete while a guest device model is attached.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      18846dee
  22. 22 6月, 2010 1 次提交
    • K
      block: Add bdrv_(p)write_sync · f08145fe
      Kevin Wolf 提交于
      Add new functions that write and flush the written data to disk immediately.
      This is what needs to be used for image format metadata to maintain integrity
      for cache=... modes that don't use O_DSYNC. (Actually, we only need barriers,
      and therefore the functions are defined as such, but flushes is what is
      implemented in this patch - we can try to change that later)
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      f08145fe
  23. 15 6月, 2010 4 次提交
    • M
      block: New bdrv_next() · 2f399b0a
      Markus Armbruster 提交于
      This is a more flexible alternative to bdrv_iterate().
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      2f399b0a
    • M
      block: Decouple block device "commit all" from DriveInfo · 6ab4b5ab
      Markus Armbruster 提交于
      do_commit() and mux_proc_byte() iterate over the list of drives
      defined with drive_init().  This misses host block devices defined by
      other means.  Such means don't exist now, but will be introduced later
      in this series.
      
      Change them to use new bdrv_commit_all(), which iterates over all host
      block devices.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      6ab4b5ab
    • M
      block: Move error actions from DriveInfo to BlockDriverState · abd7f68d
      Markus Armbruster 提交于
      That's where they belong semantically (block device host part), even
      though the actions are actually executed by guest device code.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      abd7f68d
    • M
      savevm: Really verify if a drive supports snapshots · feeee5ac
      Miguel Di Ciurcio Filho 提交于
      Both bdrv_can_snapshot() and bdrv_has_snapshot() does not work as advertized.
      
      First issue: Their names implies different porpouses, but they do the same thing
      and have exactly the same code. Maybe copied and pasted and forgotten?
      bdrv_has_snapshot() is called in various places for actually checking if there
      is snapshots or not.
      
      Second issue: the way bdrv_can_snapshot() verifies if a block driver supports or
      not snapshots does not catch all cases. E.g.: a raw image.
      
      So when do_savevm() is called, first thing it does is to set a global
      BlockDriverState to save the VM memory state calling get_bs_snapshots().
      
      static BlockDriverState *get_bs_snapshots(void)
      {
          BlockDriverState *bs;
          DriveInfo *dinfo;
      
          if (bs_snapshots)
              return bs_snapshots;
          QTAILQ_FOREACH(dinfo, &drives, next) {
              bs = dinfo->bdrv;
              if (bdrv_can_snapshot(bs))
                  goto ok;
          }
          return NULL;
       ok:
          bs_snapshots = bs;
          return bs;
      }
      
      bdrv_can_snapshot() may return a BlockDriverState that does not support
      snapshots and do_savevm() goes on.
      
      Later on in do_savevm(), we find:
      
          QTAILQ_FOREACH(dinfo, &drives, next) {
              bs1 = dinfo->bdrv;
              if (bdrv_has_snapshot(bs1)) {
                  /* Write VM state size only to the image that contains the state */
                  sn->vm_state_size = (bs == bs1 ? vm_state_size : 0);
                  ret = bdrv_snapshot_create(bs1, sn);
                  if (ret < 0) {
                      monitor_printf(mon, "Error while creating snapshot on '%s'\n",
                                     bdrv_get_device_name(bs1));
                  }
              }
          }
      
      bdrv_has_snapshot(bs1) is not checking if the device does support or has
      snapshots as explained above. Only in bdrv_snapshot_create() the device is
      actually checked for snapshot support.
      
      So, in cases where the first device supports snapshots, and the second does not,
      the snapshot on the first will happen anyways. I believe this is not a good
      behavior. It should be an all or nothing process.
      
      This patch addresses these issues by making bdrv_can_snapshot() actually do
      what it must do and enforces better tests to avoid errors in the middle of
      do_savevm(). bdrv_has_snapshot() is removed and replaced by bdrv_can_snapshot()
      where appropriate.
      
      bdrv_can_snapshot() was moved from savevm.c to block.c. It makes more sense to me.
      
      The loadvm_state() function was updated too to enforce that when loading a VM at
      least all writable devices must support snapshots too.
      Signed-off-by: NMiguel Di Ciurcio Filho <miguel.filho@gmail.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      feeee5ac
  24. 04 6月, 2010 1 次提交
  25. 28 5月, 2010 1 次提交