On Thu, Mar 22, 2012 at 11:32:44AM +0200, 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?
Correcting myself: loading of _config_ files on /usr/share. ROM images are opaque data to be presented to the guest somehow, just like a disk image or kernel binary. But maybe keymaps will become "configuration" someday, I really don't know. > > > > > > 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 current design direction Qemu seems to be following is different from that: hardware description is also considered "configuration" just like actual machine configuration. Anthony, please correct me if I am wrong. What you propose is to have two levels of "configuration" (or descriptions, or whatever we call it): 1) Hardware descriptions (or templates, or models, whatever we call it), that are not editable by the user (and not disabled by -nodefconfig). This may include CPU models, hardware emulation implemented in another language, machine-types, and other stuff that is part of "what Qemu always provides". 2) Actual machine configuration file, that is configurable and editable by the user, and normally loaded from /etc on from the command-line. The only problem is: the Qemu design simply doesn't have this distinction today (well, it _has_, the only difference is that today item (1) is almost completely coded inside tables in .c files). So if we want to go in that direction we have to agree this will be part of the Qemu design. I am not strongly inclined either way. Both approaches look good to me, we just have to decide where we are going, because we're are in this weird position todady because we never decided it explicitly, libvirt expected one thing, and we implemented something else. On the one hand I think the "two-layer" design gives us more freedom to move stuff outside .c files and change implementation details, and fits how we have been doing until today with machine types and built-in CPU models, keymaps, etc. On the other hand, I think not having this distinction between "machine configuration" and "hardware description" may be a good thing. For example: today there are two different ways of enabling a feature on a CPU: defining a new model, and adding a flag to "-cpu". And I think this asymmetry shouldn't be there: you just need a good system to define a CPU, a good set of defaults/templates, and a good system to base your configuration on those defaults/teampltes, no need to have two separate "CPU definition languages". Also, we wouldn't have to code things twice if we want to load an internal hardware description externally _and_ make some hardware details configurable one day: we just do it once: decide how it will be configured, and store it on the configuration file. Maybe the same thing can be applied to machine types: machine types can become "configuration" too, but just a configuration template to be used as base, and can be augmented/extended on the user-provided configuration file. > > > > > (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? If it is not loaded, it is a configuration mistake. If you are reusing something defined somewhere, it would be your responsibility to make sure the file where the model is defined is present. On most cases you wouldn't use -nodefconfig and it would be shipped with Qemu and you shouldn't worry. If you used -nodefconfig, you load the CPU models file explicitly using -readconfig. > > > > > > > > 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. This is the root of the disagreement, it seems: they are not considered different today. Today cpudefs are on a config file inside /etc. One may argue that this was a mistake in the first place, but that's the design we have today. > -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. I think the approach today is: - Qemu loads defaults from default config files; - Machine description files would be given using -readconfig and they would _augment_ the defaults from the default config files. With this interface, -nodefconfig is necessary and useful. But if we consider that "configuration" = "machine description file", and a machine description file would never include the CPU models themselves, that would be a different approach. -- Eduardo
