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

[Corey Bryant]

On 06/27/2012 04:43 AM, Kevin Wolf wrote:
> 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 at redhat.com> 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
>

Yes, the refcount getting to 0 while the fd is still in use is a tough 
one.  It just seems like the management app would be better equipped to 
understand when a drive is no longer needed.  Isn't this what drive_del 
is for?  If qemu is never told that the drive is no longer needed, then 
the fd remains on the monitor, and it's not a leak.

-- 
Regards,
Corey