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

On Thu, Mar 22, 2012 at 11:32:44AM +0200, Gleb Natapov wrote: 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. 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. 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. 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. 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