qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 4/4] qemu-config: Add new -add-fd command lin


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v3 4/4] qemu-config: Add new -add-fd command line option
Date: Wed, 17 Oct 2012 16:02:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

Am 17.10.2012 06:16, schrieb Eric Blake:
> I'm still seeing the corner case of:
> 
> qemu-kvm -add-fd fd=3,set=1 -add-fd fd=4,set=2 4<&-
> 
> where the dup(3) will populate fd 4 prior to the point where we get to
> process the -add-fd fd=4 command to notice that the user started
> qemu-kvm with fd 4 closed, and thus qemu will silently proceed to use
> the wrong fd.
> 
> On the other hand, I'm not sure if that corner case is worth worrying
> about, or if we just chalk it up to user stupidity (aka libvirt
> programmer stupidity) if they did something like that (most likely,
> because the management app forgot to clear FD_CLOEXEC before exec()ing
> qemu-kvm).

If you specify an FD number that isn't actually open when qemu is
stared, you can get any FD that qemu opens internally. I think the
correct answer to this problem is "then don't do that".

> Hmm, this makes me wonder if I can do something crazy like:
> 
> qemu-kvm -add-fd fd=4,set=1 -qmp /dev/fdset/1
> 
> to open a monitor on the fd I just passed in? 

I think so. At least on my side it was intended to allow this.

> And what if so, what then
> happens on that monitor if I request that fdset 1 be removed?

The same as with block devices: The fd stays open until the monitor
connection is closed. A closed monitor also triggers fd garbage
collection, so at this point the original fd would be closed (well,
assuming that you had only one monitor).

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]