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

On 03/25/2012 04:59 PM, Anthony Liguori wrote: > On 03/25/2012 09:46 AM, Avi Kivity wrote: >> On 03/25/2012 04:36 PM, Anthony Liguori wrote: >>>> Apart from the command line length, it confuses configuration with >>>> definition. >>> >>> >>> There is no distinction with what we have today. Our configuration >>> file basically corresponds to command line options and as there is no >>> distinction in command line options, there's no distinction in the >>> configuration format. >> >> We don't have command line options for defining, only configuring. > > That's an oversight. There should be a -cpudef option. It's a > QemuOptsList. > >> Again, defining = #define > > I think -global fits your definition of #define... Yes (apart from the corner case of modifying a default-instantiated device). >>> B) A management tool has complete control over cpu definitions without >>> modifying the underlying filesystem. -nodefconfig will prevent it >>> from loading and the management tool can explicitly load the QEMU >>> definition (via -readconfig, potentially using a /dev/fd/N path) or it >>> can define it's own cpu definitions. >> >> Why does -nodefconfig affect anything? > > > Because -nodefconfig means "don't load *any* default configuration > files". Put the emphasis around *configuration*.

"#define westmere blah" is not configuration, otherwise the meaning of configuration will drift over time. -cpu blah is, of course.

>> The file defines westmere as an alias for a grab bag of options. >> Whether it's loaded or not is immaterial, unless someone uses one of the >> names within. > > But you would agree, a management tool should be able to control > whether class factories get loaded, right? No, why? But perhaps I don't entirely get what you mean by "class factories". Aren't they just implementations of virtual Device *new_instance(...) = 0? if so, why not load them?

>> Otherwise, the meaning of -nodefconfig changes as more stuff is moved >> out of .c and into .cfg. > > What's the problem with this? The command line becomes unstable if you use -nodefconfig.

>>> >>> In my target-$(ARCH).cfg, I have: >>> >>> [machine] >>> enable-kvm = "on" >>> >>> Which means I don't have to use -enable-kvm anymore. But if you look >>> at a tool like libguestfs, start up time is the most important thing >>> so avoiding unnecessary I/O and processing is critical. >> >> So this is definitely configuration (applies to the current instance) as >> opposed to target-x86_64.cfg, which doesn't. > > > I'm not sure which part you're responding to.. I was saying that target-x86_64.cfg appears to be definitions, not configuration, and was asking about qemu.cfg (which is configuration). >> As far as I can tell, the only difference is that -nodefconfig -cpu >> westmere will error out instead of working. But if you don't supply >> -cpu westmere, the configuration is identical. > > What configuration? > > Let me ask, what do you think the semantics of -nodefconfig should > be? I'm not sure I understand what you're advocating for. > -nodefconfig = create an empty machine, don't assume anything (=don't read qemu.cfg) let me build it out of all those lego bricks. Those can be defined in code or in definition files in /usr/share, I don't care. Maybe that's -nodevices -vga none. But in this case I don't see the point in -nodefconfig. Not loading target_x86-64.cfg doesn't buy the user anything, since it wouldn't affect the guest in any way.