From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShL4t-0000uM-NL for qemu-devel@nongnu.org; Wed, 20 Jun 2012 09:36:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ShL4l-00074x-10 for qemu-devel@nongnu.org; Wed, 20 Jun 2012 09:36:11 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:41625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShL4k-00073i-TG for qemu-devel@nongnu.org; Wed, 20 Jun 2012 09:36:02 -0400 Received: from /spool/local by e2.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Jun 2012 09:35:58 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 9E2086E804B for ; Wed, 20 Jun 2012 09:31:22 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q5KDVMxq130640 for ; Wed, 20 Jun 2012 09:31:22 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q5KJ2DVl024375 for ; Wed, 20 Jun 2012 15:02:14 -0400 Message-ID: <4FE1D09F.8070704@linux.vnet.ibm.com> Date: Wed, 20 Jun 2012 09:31:11 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1339689305-27031-1-git-send-email-coreyb@linux.vnet.ibm.com> <4FE09EE3.9070603@redhat.com> <4FE0A15F.7070606@redhat.com> <4FE0A579.40307@redhat.com> <4FE17AE9.90205@redhat.com> <20120620083122.GC20792@redhat.com> <4FE1B308.2080100@redhat.com> In-Reply-To: <4FE1B308.2080100@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 0/5] file descriptor passing using pass-fd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, libvir-list@redhat.com, Jeff Cody , qemu-devel@nongnu.org, Luiz Capitulino , pbonzini@redhat.com On 06/20/2012 07:24 AM, Eric Blake wrote: > On 06/20/2012 02:31 AM, Daniel P. Berrange wrote: > >>> This might mean that libvirt should only closefd the file when it >>> becomes unused (like after hot unplug); or that qemu must keep it open >>> internally even after closefd as long as the block device is still in use. >> >> As it works today, the only time libvirt would call "closefd", is if >> the monitor command it was trying to use the FD with (eg drive_add) >> failed. If drive_add was successfully run, then libvirt would not be >> invoking closefd. > > But right now, the only time libvirt uses 'getfd' is with commands like > 'migrate' that implicitly close the fd after it is used by name; we > don't have any experience in using fds by '/dev/fd/nn' notation instead > of name. It is the fact that /dev/fd/nn will allow us to use 'pass-fd' > in more situations in before, by dup()ing the fd, that libvirt all the > sudden becomes responsible for using 'closefd' at the appropriate moments. > > I guess I can live with a rule that libvirt must not call 'closefd' on > any fd that it might later want to reassign to a new copy of the fd; > that is, with backing chains, if libvirt originally calls 'pass-fd > drive-virtio1' with an O_RDONLY fd and gets back 21, then libvirt must > not call 'closefd drive-virtio1' until it knows drive-virtio1 is no > longer needed. Converting the 'drive-virtio1' fd to O_RDWR while still > keeping it at /dev/fd/21 could be done via 'pass-fd -f drive-virtio1', > where -f is an optional bool parameter to force a reassociation of a > given name back to the previously assigned value instead of the normal > error path for accidentally passing an fd to an already in-use name. > It sounds like the flow would be: 'pass-fd drive-virtio1' of O_RDONLY fd --> guest gets fd 21 'pass-fd -f drive-virtio1' of O_WRONLY fd --> guest gets fd 21? But I'm not clear as to how you would retain file descriptor 21 in the guest when using 'pass-fd -f drive-virtio1'. The fd is created as a result of passing via SCM_RIGHTS, which assigns the next available fd. We don't have control over what fd is assigned, do we? -- Regards, Corey