>From 8cd4978c9be6ff2bcc414bb1c1b258b96b9a74c1 Mon Sep 17 00:00:00 2001 From: Markus Armbruster <arm...@redhat.com> 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 <arm...@redhat.com> --- 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