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

[Gleb Natapov <gleb@redhat.com>]

On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote:
> 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@. 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.
> 
And it will be rejected since cpu models are not part of configuration,
but QEMU internals stored in outside file. We have -L switch to tell
qemu where such things should be loaded from and that's it.

> 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.
> 
If cpu models are not part of configuration they should not be affected
by configuration mechanism. You are just avoiding addressing the real
question that if asked above.

--
			Gleb.