[Top][All Lists]

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

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

From: Corey Bryant
Subject: Re: [Qemu-devel] [PATCH v3 0/5] file descriptor passing using pass-fd
Date: Wed, 20 Jun 2012 09:31:11 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

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?


reply via email to

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