[libvirt] [PATCH v3] qemu: Pass file descriptor when using TPM passthrough

[Eric Blake]

On 02/06/2015 10:49 AM, Daniel P. Berrange wrote:

>> I'm still trying to figure out how virCommandReorderFDs() got into the
>> picture (I didn't write that section of the code); when I originally
>> worked on virCommand, the only way to pass fds to the child was in
>> direct positions (same fd in child as in parent), not by remapping one
>> fd in the parent to another position in the child, except for the three
>> standard descriptors.  It looks like virCommandReorderFDs was added to
>> allow remapping other fds and populates the LISTEN_FDS environment
>> variable with how many fds were thus mapped.  So the two approaches
>> don't really mix.  Do we ever use virCommandPassListenFDs() on a
>> virCommand that will also do raw fd passthrough?  Maybe the real thing
>> to do is to track at virCommand build-up time that only one of the two
>> passthrough methods can be used, and fail loudly if a programmer tries
>> to do both methods at once.
> 
> Or instead of virCommandPassFD() which only takes a source FD number,
> we could have added a virComandPassFDRemap which takes a source and
> target FD number. That way we don't have a global "reorder FDs" concept
> that can break in unexpected ways - we would only ever re-order FDs for
> which an explicitly target FD was requested.

But then we have to be careful that there are no collisions between
inherited-in-place and reordered fds.  My argument is that reordering
ALWAYS ensures we don't have to worry about collisions between different
registration styles, because we no longer have different registration
styles.

> 
>> Or maybe we should ALWAYS prepare to remap fds in the child, so that the
>> child receives fds in contiguous order with no gaps.  It might simplify
>> the code base to always reorder things, and have the mapping done up
>> front.  That is, change the virCommandPassFD() function to return an
>> integer of which next consecutive fd the child will see, or -1 on
>> failure.  Callers that then need to alter the command line of the child
>> will have to pay attention to the return value (something a bit
>> different than most virCommand build-up, which intentionally defer error
>> checking to the very end), but it might be worth it.
> 
> This might be simplest way to go - I'm just wondering if it will cause
> us any other type of fun problems

And it sounds like Stefan is looking to me to play with it and see what
breaks.  Oh well, I guess I walked into that one :)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150206/5013a436/attachment-0001.sig>