[Qemu-devel] [RFC PATCH] block: Fix eject -f for locked devices

[Markus Armbruster]

>From 8cd4978c9be6ff2bcc414bb1c1b258b96b9a74c1 Mon Sep 17 00:00:00 2001
From: Markus Armbruster <address@hidden>
Date: Fri, 18 Feb 2011 15:54:02 +0100

After forcefully ejecting media locked by the guest, you can't ever
again insert new media.

Example:

    (qemu) info block
    hda: type=hd removable=0 file=test.img ro=0 drv=raw encrypted=0
    cd: type=cdrom removable=1 locked=1 file=x.iso ro=0 drv=raw encrypted=0
    (qemu) eject cd
    Device 'cd' is locked
    (qemu) eject -f cd
    (qemu) info block
    hda: type=hd removable=0 file=test.img ro=0 drv=raw encrypted=0
    cd: type=cdrom removable=1 locked=1 [not inserted]
    (qemu) change cd x.iso
    Device 'cd' is locked

Signed-off-by: Markus Armbruster <address@hidden>
---
I'm not entirely sure this is the appropriate fix, and that's why
there's RFC in the subject.

Both IDE and SCSI devices expose their drive's BlockDriverState member
locked to the guest via mode sense.

What does real hardware do when I force-eject media (typically by
rummaging in that little hole with a paperclip)?  Does it actively
notify the OS?  Does mode sense change?

A possible alternative fix is to make do_change_block() ignore
bdrv_is_locked() when inserting media into an empty drive.

 block.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index b476479..295cf7b 100644
--- a/block.c
+++ b/block.c
@@ -682,6 +682,7 @@ void bdrv_close(BlockDriverState *bs)
         }
 
         /* call the change callback */
+        bs->locked = 0;
         bs->media_changed = 1;
         if (bs->change_cb)
             bs->change_cb(bs->change_opaque, CHANGE_MEDIA);
-- 
1.7.2.3