From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBpdU-0000DW-DN for qemu-devel@nongnu.org; Sun, 25 Mar 2012 11:45:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBpdS-0002vv-Gz for qemu-devel@nongnu.org; Sun, 25 Mar 2012 11:45:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBpdS-0002vr-8T for qemu-devel@nongnu.org; Sun, 25 Mar 2012 11:45:38 -0400 Message-ID: <4F6F3D97.5010608@redhat.com> Date: Sun, 25 Mar 2012 17:45:27 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20120313145319.GD25451@otherpad.lan.raisama.net> <20120322093244.GE22368@redhat.com> <4F6B5553.20601@codemonkey.ws> <20120322171445.GJ25451@otherpad.lan.raisama.net> <4F6B850D.9000505@codemonkey.ws> <20120325094920.GJ22368@redhat.com> <4F6F15D2.8000504@codemonkey.ws> <4F6F18E4.2040905@redhat.com> <4F6F19AC.1080009@codemonkey.ws> <4F6F1A50.5090502@redhat.com> <20120325145842.GB11793@redhat.com> <4F6F34AC.2050707@codemonkey.ws> <4F6F375F.6090000@redhat.com> <4F6F3A08.2070609@codemonkey.ws> In-Reply-To: <4F6F3A08.2070609@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: libvir-list@redhat.com, Jiri Denemark , Eduardo Habkost , Gleb Natapov , qemu-devel@nongnu.org On 03/25/2012 05:30 PM, Anthony Liguori wrote: > On 03/25/2012 10:18 AM, Avi Kivity wrote: >> On 03/25/2012 05:07 PM, Anthony Liguori wrote: >>>> As log as qemu -nodefconfig -cpu westmere -M pc1.1 >>> >>> >>> -nodefconfig is going to eventually mean that -cpu westmere and -M >>> pc-1.1 will not work. >>> >>> This is where QEMU is going. There is no reason that a normal user >>> should ever use -nodefconfig. >> >> I don't think anyone or anything can use it, since it's meaning is not >> well defined. "not read any configuration files" where parts of qemu >> are continually moved out to configuration files means its a moving >> target. > > I think you assume that all QEMU users care about forward and > backwards compatibility on the command line about all else. > > That's really not true. The libvirt folks have stated repeatedly that > command line backwards compatibility is not critical to them. They > are happy to require that a new version of QEMU requires a new version > of libvirt. I don't think this came out of happiness, but despair. Seriously, keeping compatibility is one of the things we work hardest to achieve, and we can't manage it for our command line? > > I'm not saying that backwards compat isn't important--it is. But > there are users who are happy to live on the bleeding edge. That's fine, but I don't see how -nodefconfig helps them. All it does is take away the building blocks (definitions) that they can use when setting up their configuration. > >> Suppose we define the southbridge via a configuration file. Does that >> mean we don't load it any more? > > Yes. If I want the leanest and meanest version of QEMU that will > start in the smallest number of milliseconds, then being able to tell > QEMU not to load configuration files and create a very specific > machine is a Good Thing. Why exclude users from being able to do this? So is this the point? Reducing startup time? I can't say I see the reason to invest so much effort in shaving a millisecond or less from this, but if we did want to, the way would be lazy loading of the configuration where items are parsed as they are referenced. -- error compiling committee.c: too many arguments to function