On Thu, Mar 22, 2012 at 10:31:21AM -0300, Eduardo Habkost wrote: > 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. > Where do you draw the line between "opaque data" and configuration. CPU models are also something that is present to a guest somehow. Are you consider ROMs to be "opaque data" because they are binary and CPU models to be config just because it is ascii file? What if we pre-process CPU models into binary for QEMU to read will it magically stop being configuration? > > > > > > > > > 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. That's a bug. Why trying to rationalize it now instead of fixing it. It was fixed in RHEL by the same person who introduced it in upstream in the first place. He just forgot to send the fix upstream. Does bug that is present for a long time is promoted to a feature? > > > 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. > Regular user has no idea that we describe some cpu models in .c code and others in config file and those that are described in config files are disappear if -nodefconfig is used and that if they disappear they should be loaded back and how exactly they should be loaded back. The only user of -nodefconfig is libvirt and currently it does unexpected things for its only user. > > > > > > > > > > > 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. > Machine configuration files do not exist today! Machine configuration is done in .c code and -nodefconfig skips the code that does that, but it does not skip the code that describes cpu models and resides in .c. So as far as .c code is concerned machine creation and cpu description are two different things, but for some reason the file with rest of cpu model descriptions is not loaded. This is madness, not design. > > > -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: There is not such thing as todays approach since there is not machine config file today. > > - 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. Jut make it possible to include one machine config file from another and you do not need -nodefconfig again. But this is completely orthogonal to the discussion if cpu models are configuration or not. > > 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 -- Gleb. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list