From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rvrtw-0005fp-Vt for qemu-devel@nongnu.org; Fri, 10 Feb 2012 09:56:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rvrts-0003eH-CS for qemu-devel@nongnu.org; Fri, 10 Feb 2012 09:56:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:21957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rvrts-0003e8-5U for qemu-devel@nongnu.org; Fri, 10 Feb 2012 09:56:36 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1AEuYlq007952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Feb 2012 09:56:35 -0500 From: Markus Armbruster References: <1328722656-22856-1-git-send-email-pbonzini@redhat.com> <1328722656-22856-4-git-send-email-pbonzini@redhat.com> <4F3522EC.90205@redhat.com> Date: Fri, 10 Feb 2012 15:56:32 +0100 In-Reply-To: <4F3522EC.90205@redhat.com> (Paolo Bonzini's message of "Fri, 10 Feb 2012 15:00:12 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 3/5] raw-posix: keep complete control of door locking if possible List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: amit.shah@redhat.com, qemu-devel@nongnu.org Paolo Bonzini writes: > On 02/10/2012 01:49 PM, Markus Armbruster wrote: >> With manage_door off: >> >> * cdrom_lock_medium() does nothing. Thus, guest OS operating the >> virtual door lock does not affect the physical door. >> >> * cdrom_eject() does nothing. Thus, guest OS moving the virtual tray >> does not affect the physical tray. > > That's because manage_door off means "we couldn't get O_EXCL to > work". udev will affect the physical tray and we cannot really compete > with it. Understood. I'm just describing behavior to make sure I understand your patch, not criticizing it. >> Compare to before this patch: >> >> * cdrom_lock_medium() fails silently. Thus, guest OS operating the >> virtual door may or may not affect the physical door. It usually does >> unless the CD-ROM is mounted in the host. >> >> * cdrom_eject() perror()s when it fails. Thus, guest OS moving the >> virtual tray may or may not affect the physocal tray. It usually does >> unless the CD-ROM is mounted in the host, or udev got its paws on it >> (I think). >> >> With manage_door on: >> >> * cdrom_lock_medium() works exactly as before, except the common failure >> mode "CD-ROM is mounted in the host" can't happen. >> >> * cdrom_eject() works exactly as before, except the common failure mode >> "CD-ROM is mounted in the host" can't happen. >> >> Is this correct? >> >> If yes, is it what we want? > > For virtio-scsi+scsi-block, we definitely want O_EXCL to remove the > device from udev and the in-kernel poller. That's because GESN > reports events only once, and we do not want the host and guest to > race on receiving events. But in order to open with O_EXCL we need to > unmount (GNOME3 doesn't have an unmount menu item anymore, which is > why I did it myself in patch 5/5). Program A unmounting a filesystem that some unknown program B mounted for its own unknown reasons doesn't feel right to me. Even when program B sucks as badly as Gnome appears to do. Especially when program A does it automatically, silently, and without a way to switch it off. > For IDE we do not need O_EXCL in principle. However, using the > emulated passthrough CD-ROM gets confusing without O_EXCL (to the user > and to the guest, always; and sometimes, to the host udev as well). > Basically, the guest tries to lock the disk, but udev runs as root so > it can unlock it under its feet as soon as you press the button. With > O_EXCL and some extra patches (waiting for Luiz's eject event > discussion), everything kinda works; still confusing to the user, but > not to the host or VM. > > I have some prototype patches to improve the situation on IDE somehow > (still a far cry from scsi-block), but I'm waiting for Luiz's eject > event patches to reach a conclusion first. > > There is also the case of emulated passthrough SCSI CD-ROM, but I > don't care much about it. > >> Shouldn't the user be able to ask for one >> of "grab the CD-ROM exclusively, else fail", "grab it if you can", >> "don't grab it even if you could"? > > Perhaps IDE could be made to work cooperatively, but right now it > doesn't. But scsi-block should fail if it cannot manage the door > because it bypasses all the CD-ROM machinery and issues SCSI commands > directly. You've made a good case for why we really, really want managed_door on. With managed_door off, both software and humans basically run around confused. Why do we even offer managed_door off then? And isn't the automatic, *silent* fallback to the rotten user experience of managed_door off a recipe for support calls? [...]