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? What does it have to do with unmount (which is purely the guest software state)? -- Alexey
