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

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.