From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54376 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Psewt-0000fx-S8 for qemu-devel@nongnu.org; Thu, 24 Feb 2011 12:25:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Psews-00046Y-Fl for qemu-devel@nongnu.org; Thu, 24 Feb 2011 12:25:55 -0500 Received: from mail-vx0-f173.google.com ([209.85.220.173]:44093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Psews-00046U-DG for qemu-devel@nongnu.org; Thu, 24 Feb 2011 12:25:54 -0500 Received: by vxb41 with SMTP id 41so684463vxb.4 for ; Thu, 24 Feb 2011 09:25:53 -0800 (PST) Message-ID: <4D669476.2030601@codemonkey.ws> Date: Thu, 24 Feb 2011 11:25:10 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop References: <1298497114-7436-1-git-send-email-aliguori@us.ibm.com> <4D65945A.3090106@codemonkey.ws> <4D6680E3.8010802@redhat.com> In-Reply-To: <4D6680E3.8010802@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, quintela@redhat.com On 02/24/2011 10:01 AM, Avi Kivity wrote: > On 02/24/2011 01:12 AM, Anthony Liguori wrote: >>> What is the plan from here? >> >> >> 1) Decouple QMP from qemu_machine_init(). This really requires the >> introduction of the new QAPI server that exists outside of the >> chardev infrastructure since chardevs are currently initialized in >> qemu_machine_init(). > > Is it really necessary? What's blocking us from initializing chardevs > early? Well.... We initialize all chardevs at once right now and what set of chardevs there are depends on the machine (by the way defaults are applied). You could initialize chardevs in two stages although that requires quite a bit of additional complexity. > > It would be a pity to divorce the monitor from chardevs, they're > really flexible. Couple considerations: 1) chardevs don't support multiple simultaneous connections. I view this as a blocker for QMP. 2) Because chardevs don't support multiple connections, we can't reasonably hook on things like connect/disconnect which means that fd's sent via SCM_RIGHTs have to be handled in a very special way. By going outside of the chardev layer, we can let fd's via SCM_RIGHTS queue up naturally and have getfd/setfd refer to the fd at the top of the queue. It makes it quite a bit easier to work with (I believe Daniel had actually requested this a while ago). 3) By treating QMP as a special case, we don't have to treat chardevs overall as a special case. This feels more right to me although I can't say I have a strong opinion formed yet. > >> 2) Make qemu_machine_init() take no parameters and just reference >> global state. >> >> 3) Teach all QMP functions to behave themselves if called before >> qemu_machine_init() >> >> 4) Introduce QMP function to call qemu_machine_init() > > An alternative is to remove all guest-visible content from > qemu_machine_init(). So machine->init() would take no parameters and > only build the static devices (power supply?). Everything else would > be hot-plugged (perhaps some would fail if the machine was started - > cold-plug only). All that qemu_machine_init() is is guest-visible content. That's the point of refactoring this. >> >> 5) Introduce new command line flag to not automatically call >> qemu_machine_init() >> >> 6) Convert all command line options to just be QMP function calls >> >> (6) can be started right now. (1) comes with the QAPI merge. (2) is >> pretty easy to do after applying this patch. (3) is probably >> something that can be done shortly after (1). (4) and (5) really >> require everything but (6) to be in place before we can meaningful do >> it. >> >> I think we can lay out much of the ground work for this in 0.15 and I >> think we can have a total conversion realistically for 0.16. That >> means that by EOY, we could invoke QEMU with no options and do >> everything through QMP. > > It's something that I've agitated for a long while, but when I see all > the work needed, I'm not sure it's cost effective. There's a lot of secondary benefits that come from doing this. QMP becomes a much stronger interface. A lot of operations that right now are only specifiable by the command line become dynamic which mitigates reboots in the long term. It also lays the ground work for a fully decoupled device model whereas the only interface between the devices and the outside world is a subset of QMP (think seccomp()). Whether creating a machine with no command line options is high value is probably irrelevant. I think we want to go in this direction regardless. Regards, Anthony Liguori