1. 06 9月, 2011 4 次提交
  2. 27 8月, 2011 1 次提交
  3. 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
  4. 23 8月, 2011 1 次提交
  5. 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
  6. 01 8月, 2011 1 次提交
  7. 19 7月, 2011 1 次提交
  8. 15 6月, 2011 1 次提交
  9. 19 5月, 2011 1 次提交
  10. 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
  11. 20 2月, 2011 1 次提交
  12. 07 2月, 2011 1 次提交
  13. 31 1月, 2011 1 次提交
  14. 17 12月, 2010 2 次提交
  15. 04 11月, 2010 1 次提交
  16. 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
  17. 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
  18. 26 7月, 2010 1 次提交
  19. 06 7月, 2010 1 次提交
  20. 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
  21. 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
  22. 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
  23. 04 6月, 2010 1 次提交
  24. 28 5月, 2010 2 次提交
  25. 27 5月, 2010 1 次提交
    • A
      Add cache=unsafe parameter to -drive · 016f5cf6
      Alexander Graf 提交于
      Usually the guest can tell the host to flush data to disk. In some cases we
      don't want to flush though, but try to keep everything in cache.
      
      So let's add a new cache value to -drive that allows us to set the cache
      policy to most aggressive, disabling flushes. We call this mode "unsafe",
      as guest data is not guaranteed to survive host crashes anymore.
      
      This patch also adds a noop function for aio, so we can do nothing in AIO
      fashion.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      016f5cf6
  26. 17 5月, 2010 1 次提交
  27. 03 5月, 2010 2 次提交
    • K
      block: bdrv_has_zero_init · f2feebbd
      Kevin Wolf 提交于
      This fixes the problem that qemu-img's use of no_zero_init only considered the
      no_zero_init flag of the format driver, but not of the underlying protocols.
      
      Between the raw/file split and this fix, converting to host devices is broken.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      f2feebbd
    • C
      block: separate raw images from the file protocol · 84a12e66
      Christoph Hellwig 提交于
      We're running into various problems because the "raw" file access, which
      is used internally by the various image formats is entangled with the
      "raw" image format, which maps the VM view 1:1 to a file system.
      
      This patch renames the raw file backends to the file protocol which
      is treated like other protocols (e.g. nbd and http) and adds a new
      "raw" image format which is just a wrapper around calls to the underlying
      protocol.
      
      The patch is surprisingly simple, besides changing the probing logical
      in block.c to only look for image formats when using bdrv_open and
      renaming of the old raw protocols to file there's almost nothing in there.
      
      For creating images, a new bdrv_create_file is introduced which guesses the
      protocol to use. This allows using qemu-img create -f raw (or just using the
      default) for both files and host devices. Converting the other format drivers
      to use this function to create their images is left for later patches.
      
      The only issues still open are in the handling of the host devices.
      Firstly in current qemu we can specifiy the host* format names
      on various command line acceping images, but the new code can't
      do that without adding some translation.  Second the layering breaks
      the no_zero_init flag in the BlockDriver used by qemu-img.  I'm not
      happy how this is done per-driver instead of per-state so I'll
      prepare a separate patch to clean this up.
      
      There's some more cleanup opportunity after this patch, e.g. using
      separate lists and registration functions for image formats vs
      protocols and maybe even host drivers, but this can be done at a
      later stage.
      
      Also there's a check for protocol in bdrv_open for the BDRV_O_SNAPSHOT
      case that I don't quite understand, but which I fear won't work as
      expected - possibly even before this patch.
      
      Note that this patch requires various recent block patches from Kevin
      and me, which should all be in his block queue.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      84a12e66
  28. 23 4月, 2010 2 次提交
    • K
      block.h: bdrv_create2 doesn't exist any more · 85de0ba5
      Kevin Wolf 提交于
      The bdrv_create2 implementation has disappeared long ago. Remove its
      prototype from the header file, too.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      85de0ba5
    • C
      block: get rid of the BDRV_O_FILE flag · 6db95603
      Christoph Hellwig 提交于
      BDRV_O_FILE is only used to communicate between bdrv_file_open and bdrv_open.
      It affects two things:  first bdrv_open only searches for protocols using
      find_protocol instead of all image formats and host drivers.  We can easily
      move that to the caller and pass the found driver to bdrv_open.  Second
      it is used to not force a read-write open of a snapshot file.  But we never
      use bdrv_file_open to open snapshots and this behaviour doesn't make sense
      to start with.
      
      qemu-io abused the BDRV_O_FILE for it's growable option, switch it to
      using bdrv_file_open to make sure we only open files as growable were
      we can actually support that.
      
      This patch requires Kevin's "[PATCH] Replace calls of old bdrv_open" to
      be applied first.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      6db95603