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

[Kevin Wolf]

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 <address@hidden> 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