From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKNc3-0003wz-Ux for qemu-devel@nongnu.org; Fri, 13 Sep 2013 03:16:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKNbv-0002T8-Bu for qemu-devel@nongnu.org; Fri, 13 Sep 2013 03:16:19 -0400 Received: from mail-ea0-x232.google.com ([2a00:1450:4013:c01::232]:63650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKNbv-0002Sv-4G for qemu-devel@nongnu.org; Fri, 13 Sep 2013 03:16:11 -0400 Received: by mail-ea0-f178.google.com with SMTP id a15so369908eae.23 for ; Fri, 13 Sep 2013 00:16:10 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5232BBC0.9080502@redhat.com> Date: Fri, 13 Sep 2013 09:16:16 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <5231A524.2080103@profitbricks.com> <20130912135836.GE18070@stefanha-thinkpad.redhat.com> <20130912142750.GK3514@dhcp-200-207.str.redhat.com> <20130913084804.6648725c@notabene.brown> In-Reply-To: <20130913084804.6648725c@notabene.brown> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] O_EXCL or not open block device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: NeilBrown Cc: Kevin Wolf , Jack Wang , Dongsu Park , Stefan Hajnoczi , qemu-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 13/09/2013 00:48, NeilBrown ha scritto: >> I'm not sure why O_EXCL would be correct on generic block >> devices when it's wrong on CD-ROMs. I think it's in fact more >> likely that other devices are shared, as backing files. > > O_EXCL make sense if you or someone else might change the contents. > If the device is read-only, or is uniformly treated as read-only, > then O_EXCL is unnecessary and could definitely get in the way. I > would be nice if we had O_SHARED and O_EXCL, but unfortunately we > don't.... I wonder if O_EXCL|O_RDONLY could be treated as a shared > lock.... Maybe one day. Even that won't really work well for CD-ROM passthrough, because ejecting a CD certainly affects the other openers but is available with O_RDONLY. A policy on sharing block devices that are used "just for the data" does not belong in QEMU, it belongs in management. As such, I don't think that QEMU should blindly use O_EXCL on all block devices. My patch series used O_EXCL for CD-ROMs only to disable kernel event polling; in other words, basically as a workaround. There are other reasons why not sharing a host CD unit makes sense; for example, ATAPI event polling is edge-triggered and simply doesn't work with multiple VMs attached. But if the sharing policy could be left exclusively to management above QEMU, it would be better to do so. I think if someone wants to attach a real CD-ROM disc to a VM just for the data (e.g. ejecting the disc will not open the real tray) they should use something like "file:/dev/sr0". Then QEMU would not use O_EXCL even with my patch series. Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMrvAAAoJEBvWZb6bTYbyZZMQAJIxy9jeo7/mKKrchvMs8uRY 3xN4IYtEJX15tAymsBCybW4t1Vr6P+N6I6zlFhdNCpY+o8Sckm5RV1a+1dJp5cz4 6JhAnEeddoZeEzBZorcpRCLkRZwiX2lECNsD2+cakXhprn5I+Mphd9xLBHb7FMZA eRKn3Fe4+wAFXXqanzy8SxjK7S6IN+0su6mfKqQF94HxLVM9f2EBlfFm20rUJ4jS PEhSJ2kPVMvanfDGUYzIfwP/eMBKJ8+95jBpcw1YBjn1U1V1c5wLguSyHGUacs8G sOc0X20vuK0bF9oMFYvkMaQHEnwKvNWg640pkqzWe4F2Oe73pim7kVAJzQGD4+s5 SnglMBsH+0wjA85KPwJOD3+Tv58mTbTLiQDQVC/hX9p1JCZPeptXYEiYhcNwWHWF RGM87PB9QuopE2TQJnRCPUDz9oZDX25cscZwKbsWriHAwTub4+PGm2LTARwC5ByM 0v+QCEzE7FmqEuE4K680iwKKVVWP/x1Mqn8/XW27+liOpL2FgBsPZDn27YcKQGlc UOHLs1X0g/4CSHNq4LacthgPNihNnLQ9TwZiO+P9HimpnfjWW3KfkxjvqaaWANot Tg13mS1GpxagXY675keddSLQ7GdBHkDh64R4hUzSmjrg/j9UQKChXz9ycArZ4b+t zEZy1H/cLiwwzEUm8hj8 =6pli -----END PGP SIGNATURE-----