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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list