[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP
From: |
Alexey Kardashevskiy |
Subject: |
Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP |
Date: |
Wed, 04 Dec 2013 22:59:42 +1100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 |
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.
--
Alexey
- [Qemu-devel] [PATCH 0/3] scsi: eject fixed, Alexey Kardashevskiy, 2013/12/03
- Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP, Markus Armbruster, 2013/12/05
- Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP, Alexey Kardashevskiy, 2013/12/05
- Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP, Paolo Bonzini, 2013/12/05
- Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP, Markus Armbruster, 2013/12/06
[Qemu-devel] [PATCH 3/3] scsi debug: print command name in debug, Alexey Kardashevskiy, 2013/12/03
[Qemu-devel] [PATCH 2/3] scsi-disk: check for meduim on ALLOW_MEDIUM_REMOVAL, Alexey Kardashevskiy, 2013/12/03