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

Anthony Liguori anthony at codemonkey.ws
Thu Mar 22 20:01:17 UTC 2012


On 03/22/2012 12:14 PM, Eduardo Habkost wrote:
> On Thu, Mar 22, 2012 at 11:37:39AM -0500, Anthony Liguori wrote:
>> On 03/22/2012 04:32 AM, Gleb Natapov wrote:
>>> On Tue, Mar 13, 2012 at 11:53:19AM -0300, Eduardo Habkost wrote:
>>>> 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
>
> Not @SYSCONFDIR@, but @DATADIR at . CPU models belong to /usr/share because
> they aren't meant to be changed by the user (I think I already explained
> why: because we have to be able to deploy fixes to them).
>
>>
>> Stanza by default.  If libvirt wants to reuse this, they can use
>> -readconfig if they use -nodefconfig.
>
> You are just repeating how you believe it should work based on the
> premise that "cpudefs are configuration". We're discussing/questioning
> this exact premise, here, and I would really appreciate to hear why the
> model Gleb is proposing is not valid.
>
> More precisely, this part:
>
>>> 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.
>
> And the related points Gleb mentioned further in this thread.

Because the next patch series that would follow would be a -cpu-defs-path that 
would be a one-off hack with a global variable and a -no-cpu-defs.

So let's avoid that and start by having a positive configuration mechanism that 
the user can use to change the path and exclude it.  My suggestion eliminate the 
need for two future command line options.

Regards,

Anthony Liguori

>




More information about the libvir-list mailing list