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

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 12/05/2013 12:12 AM, Markus Armbruster wrote:
> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> 
>> On 12/04/2013 08:33 PM, Markus Armbruster wrote:
>>> Paolo Bonzini <pbonzini@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