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

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

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?

-- 
Regards,
Corey