Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Gleb Natapov <gleb@redhat.com>]

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.

> 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.