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

Eduardo Habkost ehabkost at redhat.com
Thu Mar 22 17:14:45 UTC 2012


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.

-- 
Eduardo




More information about the libvir-list mailing list