On 10/10/2012 08:20 AM, Corey Bryant wrote:
This option can be used for passing file descriptors on the
command line. It mirrors the existing add-fd QMP command which
allows an fd to be passed to QEMU via SCM_RIGHTS and added to an
fd set.
This can be combined with commands such as -drive to link file
descriptors in an fd set to a drive:
qemu-kvm -add-fd fd=4,set=2,opaque="rdwr:/path/to/file"
-add-fd fd=5,set=2,opaque="rdonly:/path/to/file"
-drive file=/dev/fdset/2,index=0,media=disk
This example adds fds 4 and 5, and the accompanying opaque
strings to the fd set with ID=2. qemu_open() already knows how
to handle a filename of this format. qemu_open() searches the
corresponding fd set for an fd and when it finds a match, QEMU
goes on to use a dup of that fd just like it would have used an
fd that it opened itself.
Missing some argument validation. Earlier, I complained about set
validation, now I'm going to complain about fd validation.
+static int parse_add_fd(QemuOpts *opts, void *opaque)
+{
+ int fd;
+ int64_t fdset_id;
+ const char *fd_opaque = NULL;
+
+ fd = qemu_opt_get_number(opts, "fd", -1);
+ fdset_id = qemu_opt_get_number(opts, "set", -1);
+ fd_opaque = qemu_opt_get(opts, "opaque");
If I call 'qemu -add-fd fd=-2,set=1', that had better fail because fd -2
does not exist. Likewise if I call 'qemu -add-fd fd=10000000,set=1'
(here, picking an fd that I know can't be opened). More subtly, 'qemu
-add-fd fd=4,set=1 4<&-' should fail, since fd 4 was not inherited down
to the qemu process. Fuzzier is whether 'qemu -add-fd fd=0,set=1' makes
sense, as that would then make stdin be competing for multiple uses;
this would be a situation that the monitor command can't duplicate, so
you have introduced new ways to possibly break things from the command
line. I'm thinking it's safest to reject fd of 0, 1, or 2 for now, and
only relax it later IF we can prove that it would be both useful and safe.
So it sounds like you need something like fcntl(fd,F_GETFL) to see that
an the fd was actually inherited, as well as validating that fd >
STDERR_FILENO.
Another missing validation check is for duplicate use. With the monitor
command, you ALWAYS have a unique fd (thanks to SCM_RIGHTS). But with
the command line, I can type 'qemu -add-fd fd=4,set=1 -add-fd
fd=4,set=2'. Oops - I've now corrupted your set layout, unless you
validate that every fd requested in -add-fd does not already reside in
any existing set.
Thinking aloud:
On the other hand, being able to pass in one fd to multiple sets MIGHT
be useful; in the SCM_RIGHTS monitor command case, I can pass the same
fd from the management perspective into multiple sets, even though in
qemu's perspective, there will be multiple fds created (one per call).
Perhaps instead of directly adding the inherited fd to a set, and having
to then sweep all sets to check for duplicates, it might make sense to
add dup(fd) to a set, so that if I call:
qemu -add-fd fd=4,set=1 -add-fd fd=4,set=2 -add-fd fd=5,set=2
what REALLY happens is that qemu adds dup(4)==6 to set 1, dup(4)==7 to
set 2, and dup(5)==8 to set 3. Then, after all ALL -add-fd have been
processed, qemu then does another pass through them calling close(4) and
close(5) (to avoid holding the original fds open indefinitely if the
corresponding sets are discarded). Hmm, notice that if you dup() before
adding to a set, then that the dup() resolves my first complaint of
validating that the inherited fd exists; it also changes the problem of
dealing with fd 0 (it would now be valid to add fd 0 to any number of
sets; but a final cleanup loop had better be careful to not call
close(0) unintentionally).
Personally, though, I'm not sure the complexity of using dup() buys us
anything, so I'm happy with the simpler solution of using fd as-is,
coupled with a check for no reuse of an fd already in a set.