From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBrl6-0002zD-Jc for qemu-devel@nongnu.org; Sun, 25 Mar 2012 14:01:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBrl4-0004ci-OY for qemu-devel@nongnu.org; Sun, 25 Mar 2012 14:01:40 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:52101) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBrl4-0004cO-Ir for qemu-devel@nongnu.org; Sun, 25 Mar 2012 14:01:38 -0400 Received: by obbwd20 with SMTP id wd20so4943898obb.4 for ; Sun, 25 Mar 2012 11:01:36 -0700 (PDT) Message-ID: <4F6F5D7E.9000808@codemonkey.ws> Date: Sun, 25 Mar 2012 13:01:34 -0500 From: Anthony Liguori 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> <4F6F3D97.5010608@redhat.com> In-Reply-To: <4F6F3D97.5010608@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Avi Kivity Cc: libvir-list@redhat.com, Jiri Denemark , Eduardo Habkost , Gleb Natapov , qemu-devel@nongnu.org On 03/25/2012 10:45 AM, Avi Kivity wrote: > 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 hate to burst your bubble, but we struggle and rarely maintain the level of compatibility you're seeking to have. I agree with you that we need to do a better job maintaining compatibility which is why I'm trying to clearly separate the things that we will never break from the things that will change over time. -nodefconfig is a moving target. If you want stability, don't use it. If you just want to prevent the user's /etc/qemu stuff from being loaded, use -no-user-config. >> >> 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. Yes, this is a feature. >>> 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? Yes, that's one reason. But maybe a user wants to have a whole different set of machine types and doesn't care to have the ones we provide. Why prevent a user from doing this? Maybe they have a management tool that attempts to totally hide QEMU from the end user and exposes a different set of machine types. It's certainly more convenient for something like the Android emulator to only have to deal with QEMU knowing about the 4 types of machines that it specifically supports. Regards, Anthony Liguori