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 >>>>/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(a)/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.