From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBk4q-0000h1-FN for qemu-devel@nongnu.org; Sun, 25 Mar 2012 05:49:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBk4o-0003HS-JG for qemu-devel@nongnu.org; Sun, 25 Mar 2012 05:49:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBk4o-0003HJ-B5 for qemu-devel@nongnu.org; Sun, 25 Mar 2012 05:49:30 -0400 Date: Sun, 25 Mar 2012 11:49:20 +0200 From: Gleb Natapov Message-ID: <20120325094920.GJ22368@redhat.com> References: <20120311124116.GI17882@redhat.com> <4F5CB3D1.4050100@codemonkey.ws> <20120311151246.GL17882@redhat.com> <4F5CC7AC.6080703@codemonkey.ws> <20120312130810.GB20654@otherpad.lan.raisama.net> <20120313145319.GD25451@otherpad.lan.raisama.net> <20120322093244.GE22368@redhat.com> <4F6B5553.20601@codemonkey.ws> <20120322171445.GJ25451@otherpad.lan.raisama.net> <4F6B850D.9000505@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F6B850D.9000505@codemonkey.ws> 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 , Avi Kivity , qemu-devel@nongnu.org On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote: > On 03/22/2012 12:14 PM, Eduardo Habkost wrote: > >On Thu, Mar 22, 2012 at 11:37:39AM -0500, Anthony Liguori wrote: > >>On 03/22/2012 04:32 AM, Gleb Natapov wrote: > >>>On Tue, Mar 13, 2012 at 11:53:19AM -0300, Eduardo Habkost wrote: > >>>>So, this problem is solved if the defaults are easily found on > >>>>/usr/share. > >>>> > >>>What problem is solved and why are we mixing machine configuration files > >>>and cpu configuration files? They are different and should be treated > >>>differently. -nodefconfig exists only because there is not machine > >>>configuration files currently. With machine configuration files > >>>libvirt does not need -nodefconfig because it can create its own machine > >>>file and make QEMU use it. So specifying machine file on QEMU's command > >>>line implies -nodefconfig. The option itself loses its meaning and can be > >>>dropped. > >> > >>No, -nodefconfig means "no default config". > >> > >>As with many projects, we can have *some* configuration required. > >> > >>The default configure should have a: > >> > >>[system] > >>readconfig=@SYSCONFDIR@/cpu-models-x86_64.cfg > > > >Not @SYSCONFDIR@, but @DATADIR@. CPU models belong to /usr/share because > >they aren't meant to be changed by the user (I think I already explained > >why: because we have to be able to deploy fixes to them). > > > >> > >>Stanza by default. If libvirt wants to reuse this, they can use > >>-readconfig if they use -nodefconfig. > > > >You are just repeating how you believe it should work based on the > >premise that "cpudefs are configuration". We're discussing/questioning > >this exact premise, here, and I would really appreciate to hear why the > >model Gleb is proposing is not valid. > > > >More precisely, this part: > > > >>>cpu-models-x86.conf is not a configuration file. It is hardware > >>>description file. QEMU should not lose capability just because you run > >>>it with -nodefconfig. -nodefconfig means that QEMU does not create > >>>machine for you, but all parts needed to create a machine that would have > >>>been created without -nodefconfig are still present. Not been able to > >>>create Nehalem CPU after specifying -nodefconfig is the same as not been > >>>able to create virtio-net i.e the bug. > > > >And the related points Gleb mentioned further in this thread. > > Because the next patch series that would follow would be a > -cpu-defs-path that would be a one-off hack with a global variable > and a -no-cpu-defs. > And it will be rejected since cpu models are not part of configuration, but QEMU internals stored in outside file. We have -L switch to tell qemu where such things should be loaded from and that's it. > So let's avoid that and start by having a positive configuration > mechanism that the user can use to change the path and exclude it. > My suggestion eliminate the need for two future command line > options. > If cpu models are not part of configuration they should not be affected by configuration mechanism. You are just avoiding addressing the real question that if asked above. -- Gleb.