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

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

 



On 02/06/2015 02:43 PM, Stefan Berger wrote:
On 02/06/2015 01:58 PM, Eric Blake wrote:
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 :)

Well, we can think it through.

Are the following changes sufficient or is there much more to it?

1) reorder the FDs all the time ; the function is invoked in virExec and we can move the call up 2 lines out of the if () branch. 2a) modify the return value as shown in the other email and propagate into virCommandPassFD and return an int here now that can be ignored by callers
  OR
2b) possibly have another function that lets one determine the fd the child will see given a passed fd

3) possibly adapt test cases...

it's not that simple unfortunately; if we started to re-order / re-map using dup() the file descriptors then all fd's that make it onto the command line, like those for -netdev and others, also need to be adapted to have that re-ordered fd on the command line. Conversely, this currently prevents us from ordering the file descriptors as well, since nothing would work without code change. So ordering the file descriptors cannot currently be done with anything that builds up a QEMU command line. So do we really need to re-order them then as part of this code change?

     Stefan



   Stefan


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]