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