From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvsGG-0006G7-8q for qemu-devel@nongnu.org; Fri, 10 Feb 2012 10:19:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvsGA-0007WD-Ak for qemu-devel@nongnu.org; Fri, 10 Feb 2012 10:19:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvsGA-0007W8-1l for qemu-devel@nongnu.org; Fri, 10 Feb 2012 10:19:38 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1AFJbpQ014275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Feb 2012 10:19:37 -0500 Message-ID: <4F353586.4050700@redhat.com> Date: Fri, 10 Feb 2012 16:19:34 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1328722656-22856-1-git-send-email-pbonzini@redhat.com> <1328722656-22856-4-git-send-email-pbonzini@redhat.com> <4F3522EC.90205@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Markus Armbruster Cc: amit.shah@redhat.com, qemu-devel@nongnu.org On 02/10/2012 03:56 PM, Markus Armbruster wrote: > 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. Sure, just expanding on the rationale. >> 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. Well, first it's a CD-ROM, so it won't cause data loss. CD burning programs use O_EXCL so QEMU will not stomp on anyone's feet while the CD is being written to. Second, it's the user who asked to use the CD-ROM in a guest. It makes sense to imply he does not want to use it in the host. Third, if there are open files or such, the unmounting will fail. And in fact in most cases you won't notice the auto unmounting. Say you're installing a guest (most common case of IDE CD passthrough). The installation program will usually eject the disc before rebooting. If you put it back in after you stop the VM and QEMU has exited, ta-dah, the disc will be remounted. > 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. Kind of. In most cases you don't care at all about the tray (for example when installing a VM from a "real" disk). You care about the tray if the guest starts using it, for example Anaconda's infamous auto-eject after testing media. Right now sometimes it's hard to convince the guest that you actually put the CD back. But if the tray is not managed, you'll never get an auto-eject and you don't have to convince anyone about anything. > 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? Regarding silence you have a point. On the other hand, when starting via libvirt everything will be silent. :( This is another point in favor of automatic unmounting, which will usually just work. It may make sense to fail completely if the unmounting fails, but then we need to do more effort to grab the disk (e.g. try /bin/umount if udisks fails). Paolo