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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/22/2012 04:32 AM, 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?
>
>>>
>>> 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.

No, -nodefconfig means "no default config".

As with many projects, we can have *some* configuration required.

The default configure should have a:

[system]
readconfig=@SYSCONFDIR@/cpu-models-x86_64.cfg

Stanza by default.  If libvirt wants to reuse this, they can use -readconfig if 
they use -nodefconfig.

Regards,

Anthony Liguori

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