From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAl1M-0002Kh-OY for qemu-devel@nongnu.org; Thu, 22 Mar 2012 12:37:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAl1F-0004mH-Mj for qemu-devel@nongnu.org; Thu, 22 Mar 2012 12:37:52 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:32834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAl1F-0004lS-Hp for qemu-devel@nongnu.org; Thu, 22 Mar 2012 12:37:45 -0400 Received: by ghrr14 with SMTP id r14so2315344ghr.4 for ; Thu, 22 Mar 2012 09:37:43 -0700 (PDT) Message-ID: <4F6B5553.20601@codemonkey.ws> Date: Thu, 22 Mar 2012 11:37:39 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <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> In-Reply-To: <20120322093244.GE22368@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: Gleb Natapov Cc: libvir-list@redhat.com, Jiri Denemark , Eduardo Habkost , Avi Kivity , qemu-devel@nongnu.org On 03/22/2012 04:32 AM, Gleb Natapov wrote: > On Tue, Mar 13, 2012 at 11:53:19AM -0300, Eduardo Habkost wrote: >> So, trying to summarize what was discussed in the call: >> >> On Mon, Mar 12, 2012 at 10:08:10AM -0300, Eduardo Habkost wrote: >>>> Let's say we moved CPU definitions to /usr/share/qemu/cpu-models.xml. >>>> >>>> Obviously, we'd want a command line option to be able to change that >>>> location so we'd introduce -cpu-models PATH. >>>> >>>> But we want all of our command line options to be settable by the >>>> global configuration file so we would have a cpu-model=PATH to the >>>> configuration file. >>>> >>>> But why hard code a path when we can just set the default path in the >>>> configuration file so let's avoid hard coding and just put >>>> cpu-models=/usr/share/qemu/cpu-models.xml in the default >>>> configuration file. >>> >>> We wouldn't do the above. >>> >>> -nodefconfig should disable the loading of files on /etc, but it >>> shouldn't disable loading internal non-configurable data that we just >>> happened to choose to store outside the qemu binary because it makes >>> development easier. >> >> The statement above is the one not fulfilled by the compromise solution: >> -nodefconfig would really disable the loading of files on /usr/share. >> > What does this mean? Will -nodefconfig disable loading of bios.bin, > option roms, keymaps? > >>> >>> Really, the requirement of a "default configuration file" is a problem >>> by itself. Qemu should not require a default configuration file to work, >>> and it shouldn't require users to copy the default configuration file to >>> change options from the default. >> >> The statement above is only partly true. The default configuration file >> would be still needed, but if defaults are stored on /usr/share, I will >> be happy with it. >> >> My main problem was with the need to _copy_ or edit a non-trivial >> default config file. If the not-often-edited defaults/templates are >> easily found on /usr/share to be used with -readconfig, I will be happy >> with this solution, even if -nodefconfig disable the files on >> /usr/share. >> >>> >>> Doing this would make it impossible to deploy fixes to users if we evern >>> find out that the default configuration file had a serious bug. What if >>> a bug in our default configuration file has a serious security >>> implication? >> >> The answer to this is: if the broken templates/defaults are on >> /usr/share, it would be easy to deploy the fix. >> >> So, the compromise solution is: >> >> - We can move some configuration data (especially defaults/templates) >> to /usr/share (machine-types and CPU models could go there). This >> way we can easily deploy fixes to the defaults, if necessary. >> - To reuse Qemu models, or machine-types, and not define everything from >> scratch, libvirt will have to use something like: >> "-nodefconfig -readconfig /usr/share/qemu/cpu-models-x86.conf" >> > 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. > >> >> (the item below is not something discussed on the call, just something I >> want to add) >> >> To make this work better, we can allow users (humans or machines) to >> "extend" CPU models on the config file, instead of having to define >> everything from scratch. So, on /etc (or on a libvirt-generated config) >> we could have something like: >> >> ============= >> [cpu] >> base_cpudef = Nehalem >> add_features = "vmx" >> ============= >> >> Then, as long as /usr/share/cpu-models-x86.conf is loaded, the user will >> be able to reuse the Nehalem CPU model provided by Qemu. >> > And if it will not be loaded? > >>> >>>> >>>> But now when libvirt uses -nodefconfig, those models go away. >>>> -nodefconfig means start QEMU in the most minimal state possible. >>>> You get what you pay for if you use it. >>>> >>>> We'll have the same problem with machine configuration files. At >>>> some point in time, -nodefconfig will make machine models disappear. >>> >>> It shouldn't. Machine-types are defaults to be used as base, they are >>> not user-provided configuration. And the fact that we decided to store >>> some data outside of the Qemu binary is orthogonal the design decisions >>> in the Qemu command-line and configuration interface. >> >> 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 Stanza by default. If libvirt wants to reuse this, they can use -readconfig if they use -nodefconfig. Regards, Anthony Liguori > >> We still have the backwards compatibility problem for pc-1.0, pc-1.1, >> and so on. But that can be discussed later, when we actually move >> machine-types to somewhere outside .c files. >> >>> >>> As I said previously, requiring generation of opaque config files (and >>> "copy the default config file and change it" is included on my >>> definition of "generation of opaque config files") is poor design, IMO. >>> I bet this even has an entry in some design anti-pattern catalog >>> somewhere. >> >> This problem is also solved if the defaults are deployed on /usr/share >> and just reused/included by the config files on /etc. >> > > -- > Gleb.