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

On 02/06/2015 09:41 AM, Stefan Berger wrote: >>> @@ -214,6 +215,12 @@ virCommandReorderFDs(virCommandPtr cmd) >>> if (!cmd || cmd->has_error || !cmd->npassfd) >>> return; >>> + if ((cmd->flags & VIR_EXEC_FIXED_FDS)) { >>> + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", >>> + _("The fds are fixed and cannot be reordered")); >>> + goto error; >>> + } >> Okay, so you are enforcing that a caller can't pick two conflicting fd >> passing methods on the same virCommand, but my point remains that the >> testsuite should prove we can hit this error case, to avoid regressions. >> Or we should redo virCommand to ALWAYS rearrange fds in the child, and >> make it possible for a caller passing an fd down to know what fd the >> child will see it as. > That's the part I don't quite follow. We are passing indices via > /dev/fdset/%d, right? At the time we build up the command line, we need > to know the index that the fd will have. If we shuffle things around > later in a way that we cannot determine at the point we build up the > command line, how would this work then? When you register an fd with virCommand, you would know at that point what fd the child will see (regardless of what the fd number was in the parent); ideally, the first fd you register will be fd 3 in the guest, the next one will be fd 4 in the guest. I'm further proposing that we number our /dev/fdset/%n after the first fd we place in the set (that is, we know the guest will see fd 3, so place it in /dev/fdset/3). The only time an fdset needs more than one member is if we pass multiple fds pointing to the same file (a read-only fd and a read-write fd, for example), but we don't have a use for that yet. > We are not passing all file descriptors to the child. So how would you > handle passing fd's 10,3,55 to the child? Do we pass empty slots for 4-9 > and 11-54 then, like pass fd = -1, so we can pass indices 10,3, and 55 > or something like that? In my proposal, the parent's 10, 3, 55 become the child's 3, 4, 5. The current code has the parent's 10 become the child's 10, with closed fds in between, except when using the newer code that packs things and merely passes an environment variable to say how many were packed. I'm proposing that we just always pack things, and make it easier to know what number we packed into, and that the parent then build the command line around the packed number instead of around the parent's number.