1. 06 12月, 2011 1 次提交
  2. 05 12月, 2011 4 次提交
  3. 11 11月, 2011 1 次提交
    • P
      block: add eject request callback · 025ccaa7
      Paolo Bonzini 提交于
      Recent versions of udev always keep the tray locked so that the kernel
      can observe "eject request" events (aka tray button presses) even on
      discs that aren't mounted.  Add support for these events in the ATAPI
      and SCSI cd drive device models.
      
      To let management cope with the behavior of udev, an event should also
      be added for "tray opened/closed".  This way, after issuing an "eject"
      command, management can poll until the guests actually reacts to the
      command.  They can then issue the "change" command after the tray has been
      opened, or try with "eject -f" after a (configurable?) timeout.  However,
      with this patch and the corresponding support in the device models,
      at least it is possible to do a manual two-step eject+change sequence.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      025ccaa7
  4. 12 9月, 2011 4 次提交
    • M
      ide/atapi scsi-disk: Make monitor eject -f, then change work · 25ad22bc
      Markus Armbruster 提交于
      change fails while the tray is locked by the guest.  eject -f forces
      it open and removes any media.  Unfortunately, the tray closes again
      instantly.  Since the lock remains as it is, there is no way to insert
      another medium unless the guest voluntarily unlocks.
      
      Fix by leaving the tray open after monitor eject.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      25ad22bc
    • M
      block: Drop BlockDriverState member removable · 9e6a4c91
      Markus Armbruster 提交于
      It's a confused mess (see previous commit).  No users remain.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      9e6a4c91
    • M
      block: Clean up remaining users of "removable" · 2c6942fa
      Markus Armbruster 提交于
      BlockDriverState member removable is a confused mess.  It is true when
      an ide-cd, scsi-cd or floppy qdev is attached, or when the
      BlockDriverState was created with -drive if={floppy,sd} or -drive
      if={ide,scsi,xen,none},media=cdrom ("created removable"), except when
      an ide-hd, scsi-hd, scsi-generic or virtio-blk qdev is attached.
      
      Three users remain:
      
      1. eject_device(), via bdrv_is_removable() uses it to determine
         whether a block device can eject media.
      
      2. bdrv_info() is monitor command "info block".  QMP documentation
         says "true if the device is removable, false otherwise".  From the
         monitor user's point of view, the only sensible interpretation of
         "is removable" is "can eject media with monitor commands eject and
         change".
      
      A block device can eject media unless a device is attached that
      doesn't support it.  Switch the two users over to new
      bdrv_dev_has_removable_media() that returns exactly that.
      
      3. bdrv_getlength() uses to suppress its length cache when media can
         change (see commit 46a4e4e6).  Media change is either monitor
         command change (updates the length cache), monitor command eject
         (doesn't update the length cache, easily fixable), or physical
         media change (invalidates length cache, not so easily fixable).
      
      I'm refraining from improving anything here, because this series is
      long enough already.  Instead, I simply switch it over to
      bdrv_dev_has_removable_media() as well.
      
      This changes the behavior of the length cache and of monitor commands
      eject and change in two cases:
      
      a. drive not created removable, no device attached
      
         The commit makes the drive removable, and defeats the length cache.
      
         Example: -drive if=none
      
      b. drive created removable, but the attached drive is non-removable,
         and doesn't call bdrv_set_removable(..., 0) (most devices don't)
      
         The commit makes the drive non-removable, and enables the length
         cache.
      
         Example: -drive if=xen,media=cdrom -M xenpv
      
         The other non-removable devices that don't call
         bdrv_set_removable() can't currently use a drive created removable,
         either because they aren't qdevified, or because they lack a drive
         property.  Won't stay that way.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      2c6942fa
    • M
      block: Drop medium lock tracking, ask device models instead · f107639a
      Markus Armbruster 提交于
      Requires new BlockDevOps member is_medium_locked().  Implement for IDE
      and SCSI CD-ROMs.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      f107639a
  5. 06 9月, 2011 1 次提交
  6. 23 8月, 2011 1 次提交
  7. 21 8月, 2011 1 次提交
  8. 01 8月, 2011 1 次提交
  9. 22 7月, 2011 1 次提交
  10. 05 7月, 2011 2 次提交
  11. 24 6月, 2011 1 次提交
  12. 08 6月, 2011 1 次提交
  13. 19 5月, 2011 2 次提交
  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. 04 4月, 2011 1 次提交
  16. 15 3月, 2011 1 次提交
    • J
      Improve error handling in do_snapshot_blkdev() · 52f9a172
      Jes Sorensen 提交于
      In case we cannot open the newly created snapshot image, try to fall
      back to the original image file and continue running on that, which
      should prevent the guest from aborting.
      
      This is a corner case which can happen if the admin by mistake
      specifies the snapshot file on a virtual file system which does not
      support O_DIRECT. bdrv_create() does not use O_DIRECT, but the
      following open in bdrv_open() does and will then fail.
      Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      52f9a172
  17. 10 2月, 2011 2 次提交
  18. 07 2月, 2011 2 次提交
  19. 31 1月, 2011 10 次提交
  20. 24 1月, 2011 2 次提交