[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

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

No, -nodefconfig means "no default config".

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

The default configure should have a:

readconfig= SYSCONFDIR@/cpu-models-x86_64.cfg

Not @SYSCONFDIR@, but @DATADIR   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.


Anthony Liguori

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]