From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47843 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtuIo-0004yS-8r for qemu-devel@nongnu.org; Sun, 27 Feb 2011 23:01:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PtuIj-0002pp-2J for qemu-devel@nongnu.org; Sun, 27 Feb 2011 23:01:42 -0500 Received: from mail-yi0-f45.google.com ([209.85.218.45]:33612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PtuIi-0002pl-UB for qemu-devel@nongnu.org; Sun, 27 Feb 2011 23:01:37 -0500 Received: by yib19 with SMTP id 19so595355yib.4 for ; Sun, 27 Feb 2011 20:01:36 -0800 (PST) Message-ID: <4D6B1E1D.2050801@codemonkey.ws> Date: Sun, 27 Feb 2011 22:01:33 -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> <4D669476.2030601@codemonkey.ws> <4D6A3679.1010009@redhat.com> In-Reply-To: <4D6A3679.1010009@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/27/2011 05:33 AM, Avi Kivity wrote: > On 02/24/2011 07:25 PM, Anthony Liguori wrote: >>> 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. > > We could initialize chardevs on demand - that should resolve any > dependencies? I think that potentially screws up the way -global works. There's some deep black magic involved in how -global, defaults, and device initialization interact. >>> >>> 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. > > What do you mean by that? Something like ,server which keeps on > listening after it a connection is established? ,server won't allow multiple simultaneous connections. CharDriverStates simply don't have a connection semantic. There can only be one thing connected to it at a time. This is why we don't use CharDriverState for VNC. We should have another abstraction for connection based backend. I'll take a go at this when I'm ready to try to get those patches in. Just to be clear though, there is a CharDriverState version of the new QMP server. This would be a second option for creating a QMP server and it takes a different command line sytnax. >> 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). > > I really don't follow... what's the connection between SCM_RIGHTS and > multiple connections? Monitors have a single fd. That fd is associated with the monitor and lives beyond the length of the connection to the monitor (recall that chardevs don't have a notion of connection life cycle). This means if a management tool forgets to do a closefd on an unused fd, there's no easy way for QEMU to automatically clean that up. IOW, a crashed management tool == fd leak in QEMU. >>>> (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. > > Only the hot-pluggable ones. Yup, but it forces us to treat options that cannot change at runtime as special cases which I think is a nice plus. Customers don't like having their guests rebooted during a scheduled downtime so we really ought to try to have as many things tunable at runtime as possible. Regards, Anthony Liguori