Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

Am 27.06.2012 00:28, schrieb Corey Bryant: > > > On 06/26/2012 04:50 PM, Luiz Capitulino wrote: >> On Tue, 26 Jun 2012 13:45:52 +0200 >> Kevin Wolf <kwolf(a)redhat.com&gt; wrote: >> >>> Am 26.06.2012 11:10, schrieb Daniel P. Berrange: >>>> I was thinking about some of the sources complexity when using >>>> FD passing from libvirt and wanted to raise one idea for discussion >>>> before we continue. >>>> >>>> With this proposed series, we have usage akin to: >>>> >>>> 1. pass_fd FDSET={M} -> returns a string "/dev/fd/N" showing QEMU's >>>> view of the FD >>>> 2. drive_add file=/dev/fd/N >>>> 3. if failure: >>>> close_fd "/dev/fd/N" >>> >>> In fact, there are more steps: >>> >>> 4. use it successfully >>> 5. close_fd "/dev/fd/N" >>> >>> I think it would well be possible that qemu just closes the fd when it's >>> not used internally any more. >> >> pass-fd could have a flag indicating qemu to do that. >> > > It seems like libvirt would be in a better position to understand when a > file is no longer in use, and then it can call close_fd. No? Of course > the the only fd that needs to be closed is the originally passed fd. > The dup'd fd's are closed by QEMU. No, libvirt doesn't know it, because the original file descriptor is still needed when qemu decides to reopen the file. So I think qemu needs some kind of refcounting anyway. One of the references is held by libvirt and it can drop it with close_fd, and the other one would be for the BlockDriverState or whatever you use the FD with. (There's a tricky part: When do you actually close the FD? If libvirt has dropped its reference and qemu reopens, for example because it has just probed the image format, we have a short time where the refcount would be 0, but we can't drop it anyway.) Kevin