[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: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP |
Date: |
Thu, 05 Dec 2013 09:01:06 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) |
Alexey Kardashevskiy <address@hidden> writes:
> On 12/05/2013 12:12 AM, Markus Armbruster wrote:
>> 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.
>
>
> 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?
START_STOP has a "load/eject" flag that causes load with start and eject
with stop.
> What does it have to do with unmount (which is purely the guest software
> state)?
Not sure I understand you here.
A guest that voluntarily ejects a medium while keeping it mounted gets
what it asked for: breakage.
- [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