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