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

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 12/05/2013 11:29 PM, Markus Armbruster wrote:
> Markus Armbruster <armbru@redhat.com> writes:
> 
>> 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.
> 
> Alexey asked me for details on IRC.
> 
>     $ qemu -nodefaults -monitor stdio -S -machine accel=kvm -m 512 -display vnc=:0 -device cirrus-vga -drive if=none,id=disk,file=test.qcow2 -device ide-hd,drive=disk,bus=ide.0 -drive if=none,id=cd,file=f16.iso -device ide-cd,drive=cd,bus=ide.1
>     QEMU 1.7.50 monitor - type 'help' for more information
>     (qemu) info block cd
> 
>     cd: f16.iso (raw)
>         Removable device: not locked, tray closed
> 
> Boot the guest (Fedora 16, no X)
> 
>     (qemu) c
> 
> The guest locked the tray:
> 
>     (qemu) info block cd
> 
>     cd: f16.iso (raw)
>         Removable device: locked, tray closed
> 
> In the guest, log in as root on the console, and run
> 
>     # eject /dev/sr0
> 
> Makes the guest open the tray:
> 
>     (qemu) info block cd
> 
>     cd: f16.iso (raw)
>         Removable device: locked, tray open
> 
> In the guest, run
> 
>     # eject -t /dev/sr0
> 
> Makes the guest close the tray:
> 
>     (qemu) info block cd
> 
>     cd: f16.iso (raw)
>         Removable device: locked, tray closed
> 
> Verify the guest can access the medium:
> 
>     # mount -r /dev/sr0 /mnt
> 
>> The somewhat unfortunate consequence is that monitor command eject can
>> only remove the medium when the tray is not locked.

Thanks!

Just out of curiosity. A lot (in fact, all around me) dvd drives do not
support trayclose as they are in laptops or servers (which use the same
laptop models). I cannot even verify how this "eject -t" exactly works - no
hardware around me. And even if I could find it, I could easily take the
disc off the tray in that short period of time between tray is open and
tray is closed but we still absolutely want "eject" + "eject -t" to work as
you described.

Why exactly? :) Only because change of behavior is bad? Just asking. Thanks.



-- 
Alexey