[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Corey Bryant
Subject: Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd
Date: Wed, 27 Jun 2012 10:34:56 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

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 <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.)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]