qemu-devel
[Top][All Lists]
Advanced

[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: Wed, 04 Dec 2013 10:33:37 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]