From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoLYd-0000Af-Rs for qemu-devel@nongnu.org; Wed, 04 Dec 2013 18:08:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VoLYW-0006jC-Tq for qemu-devel@nongnu.org; Wed, 04 Dec 2013 18:08:39 -0500 Received: from mail-pb0-f42.google.com ([209.85.160.42]:62452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoLYW-0006ie-KN for qemu-devel@nongnu.org; Wed, 04 Dec 2013 18:08:32 -0500 Received: by mail-pb0-f42.google.com with SMTP id uo5so24638098pbc.29 for ; Wed, 04 Dec 2013 15:08:31 -0800 (PST) Message-ID: <529FB5EA.7010801@ozlabs.ru> Date: Thu, 05 Dec 2013 10:08:26 +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> <529F192E.7080204@ozlabs.ru> <8761r4bvzq.fsf@blackfin.pond.sub.org> In-Reply-To: <8761r4bvzq.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 Cc: Paolo Bonzini , Paul Mackerras , qemu-devel@nongnu.org On 12/05/2013 12:12 AM, Markus Armbruster wrote: > Alexey Kardashevskiy writes: > >> 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. > > 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? What does it have to do with unmount (which is purely the guest software state)? -- Alexey