Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP

[Markus Armbruster]

Alexey Kardashevskiy <address@hidden> writes:

> On 12/04/2013 08:33 PM, Markus Armbruster wrote:
>> Paolo Bonzini <address@hidden> 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.