From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoB7U-0007uR-9u for qemu-devel@nongnu.org; Wed, 04 Dec 2013 07:00:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VoB7M-0002BB-U5 for qemu-devel@nongnu.org; Wed, 04 Dec 2013 06:59:56 -0500 Received: from mail-pb0-f47.google.com ([209.85.160.47]:41338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoB7M-0002B4-Nw for qemu-devel@nongnu.org; Wed, 04 Dec 2013 06:59:48 -0500 Received: by mail-pb0-f47.google.com with SMTP id um1so23154659pbc.6 for ; Wed, 04 Dec 2013 03:59:47 -0800 (PST) Message-ID: <529F192E.7080204@ozlabs.ru> Date: Wed, 04 Dec 2013 22:59:42 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1386132925-16728-1-git-send-email-aik@ozlabs.ru> <1386132925-16728-2-git-send-email-aik@ozlabs.ru> <529EEE9F.50007@redhat.com> <87d2ldklji.fsf@blackfin.pond.sub.org> In-Reply-To: <87d2ldklji.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Paolo Bonzini Cc: Paul Mackerras , qemu-devel@nongnu.org On 12/04/2013 08:33 PM, Markus Armbruster wrote: > Paolo Bonzini 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