From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35036 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9HA1-0001VO-2o for qemu-devel@nongnu.org; Mon, 11 Apr 2011 09:28:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9H9u-0001uE-MU for qemu-devel@nongnu.org; Mon, 11 Apr 2011 09:28:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9H9u-0001tj-Du for qemu-devel@nongnu.org; Mon, 11 Apr 2011 09:28:02 -0400 Message-ID: <4DA301DA.7050407@redhat.com> Date: Mon, 11 Apr 2011 16:27:54 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] To O_EXCL or not to O_EXCL open host_cdrom References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , qemu-devel , Markus Armbruster , Ryan Harper , Amit Shah , Christoph Hellwig On 04/08/2011 02:33 PM, Stefan Hajnoczi wrote: > Amit and I were discussing the pros and cons of using O_EXCL to open > host CD-ROM devices on IRC but this discussion could benefit from more > input. > > Linux block devices (like /dev/sr0 CD-ROMs) can be opened with O_EXCL > and only one userspace process will succeed at a time. This prevents > programs from interfering with each other. The polling daemons, hald > and udisks, use O_EXCL and mount does too. > > Today QEMU does not use O_EXCL and will therefore access host CD-ROMs > while they are in use by other programs. This also means that > programs can be started on the host while QEMU is already running that > may interfere with the virtual machine's ability to access the CD-ROM > (for example by ejecting it). Also, performance would likely be ruined if the disk wasn't cached (likely with a DVD). CD-ROMs seek very slowly. It would be even funnier if we supported cd-writers. > Therefore, it sounds reasonable to switch to O_EXCL to prevent > interfering with other programs and to prevent other programs > interfering with QEMU. > > On the downside, it will no longer be possible to share a host CD-ROM > between multiple virtual machines or to mount it on host while passing > it through to a guest. These scenarios are not safe because on of the > clients could eject the device, spoiling the party for everyone else. > However, it is a handy feature for putting installation media into a > machine and installing several guests at the same time. You'd probably benefit a lot more by copying the media to disk. > The other concern I have about using O_EXCL is that we expose > ourselves to race conditions if there is ever a need to re-open the > device. When QEMU closes its file descriptor another program may be > scheduled to run and open the device with O_EXCL. Now QEMU will not > be able to open the CD-ROM anymore. From the guest perspective this > could be at an odd time and we'd have to start failing requests. > Today we do not re-open host CD-ROMs though so this isn't a pressing > problem. We really should avoid re-open whenever possible. The standard response to such questions is "let's add another option", but in this case I don't think we should. Like Amit says, this is a niche use case. -- error compiling committee.c: too many arguments to function