Alexey Kardashevskiy <a...@ozlabs.ru> writes: > On 12/05/2013 12:12 AM, Markus Armbruster wrote: >> Alexey Kardashevskiy <a...@ozlabs.ru> writes: >> >>> On 12/04/2013 08:33 PM, Markus Armbruster wrote: >>>> Paolo Bonzini <pbonz...@redhat.com> writes: >>>> >>>>> Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto: >>>>>> Normally the user is expected to eject DVD if it is not locked by >>>>>> the guest. eject_device() makes few checks and calls bdrv_close() >>>>>> if DVD is not in use. >>>>>> >>>>>> However it is still possible to eject DVD even if it is in use. >>>>>> For that, QEMU sets "eject requested" flag, the guest reads it, issues >>>>>> ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, >>>>>> bdrv_close() is not called anywhere so it remains "inserted" in QEMU's >>>>>> terms. >>>>> >>>>> This is expected behavior, and matches what IDE does. >>>>> >>>>> Markus, can you confirm? >>>> >>>> Confirmed. See commit 4be9762. >>>> >>>> Alexey, monitor commands eject does two things: it first opens the tray, >>>> and if that works, it removes the medium. >>>> >>>> If the tray is locked closed, it tells the device model that eject was >>>> requested. Works just like the physical eject button. >>>> >>>> With -f, it then rips out the medium. This is similar to opening the >>>> tray with a unbent paperclip. Let's ignore this case. >>>> >>>> The scsi-cd device model tells the guest about the eject request. A >>>> well-behaved guest will then command the device to unlock and open the >>>> tray. >>>> >>>> The guest uses the same commands on behalf of its applications, >>>> e.g. /usr/bin/eject. >>>> >>>> Your patch changes behavior of "eject /dev/sr0 && eject -t /dev/sr0": >>>> you no longer get the same medium back. You normally do with real >>>> hardware. >>>> >>>> The somewhat unfortunate consequence is that monitor command eject can >>>> only remove the medium when the tray is not locked. >>> >>> >>> Oh. Wow. Nice :-/ >>> >>> Ok. So. It is expected that the real system will close the tray back if it >>> was mounted, is not it? >>> >>> Right now, after "eject" "info block" is like this: >>> >>> cd1: virtimg/Fedora-19-ppc64-netinst.iso (raw) >>> Removable device: locked, tray open >>> >>> And the mountpoint does not work in the guest. The state above even >>> persists after "umount" in the guest. It only becomes correct again >>> (tray==closed) when I mount DVD again. >>> >>> Is it all expected to work like this? Thanks. >> >> Can't reproduce, but can reproduce something similar. Freshly booted >> guest running RHEL-7 alpha, with the CD mounted: >> >> (qemu) info block cd >> >> cd: r7.iso (raw, read-only) >> Removable device: locked, tray closed >> >> Looks good. Try to eject: >> >> (qemu) eject cd >> Device 'cd' is locked >> >> Looks good. This should have signalled the guest "user wants to eject". >> The guest should either ignore it, or unmount, unlock and eject. >> Apparently, it does that: >> >> (qemu) info block cd >> >> cd: r7.iso (raw, read-only) >> Removable device: locked, tray closed >> (qemu) eject cd >> Device 'cd' is locked >> (qemu) info block cd >> >> cd: r7.iso (raw, read-only) >> Removable device: locked, tray closed >> (qemu) info block cd >> >> cd: r7.iso (raw, read-only) >> Removable device: not locked, tray open >> >> Except it forgets to unmount! dmesg has "VFS: busy inodes on changed >> media or resized disk sr0". >> >> Need somebody to find out how exactly this fails, and whether it's a >> guest bug or a QEMU bug. > > > The guest unlocks DVD (by sending ALLOW PERMIT MEDIUM REMOVAL) and stops > DVD (by sending START_STOP). Is there any other message missing which would > do real physical eject?
START_STOP has a "load/eject" flag that causes load with start and eject with stop. > What does it have to do with unmount (which is purely the guest software > state)? Not sure I understand you here. A guest that voluntarily ejects a medium while keeping it mounted gets what it asked for: breakage.