From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAoCL-0002E7-GJ for qemu-devel@nongnu.org; Thu, 22 Mar 2012 16:01:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAoCJ-0005oG-LB for qemu-devel@nongnu.org; Thu, 22 Mar 2012 16:01:24 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:44733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAoCJ-0005oB-H0 for qemu-devel@nongnu.org; Thu, 22 Mar 2012 16:01:23 -0400 Received: by ghrr14 with SMTP id r14so2576915ghr.4 for ; Thu, 22 Mar 2012 13:01:22 -0700 (PDT) Message-ID: <4F6B850D.9000505@codemonkey.ws> Date: Thu, 22 Mar 2012 15:01:17 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <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> In-Reply-To: <20120322171445.GJ25451@otherpad.lan.raisama.net> 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: Eduardo Habkost Cc: libvir-list@redhat.com, Jiri Denemark , qemu-devel@nongnu.org, Gleb Natapov , Avi Kivity 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. 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. Regards, Anthony Liguori >