From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBpBN-0000vb-33 for qemu-devel@nongnu.org; Sun, 25 Mar 2012 11:16:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBpBK-00064k-Us for qemu-devel@nongnu.org; Sun, 25 Mar 2012 11:16:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBpBK-00064a-Mn for qemu-devel@nongnu.org; Sun, 25 Mar 2012 11:16:34 -0400 Message-ID: <4F6F36C7.8010206@redhat.com> Date: Sun, 25 Mar 2012 17:16:23 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20120311124116.GI17882@redhat.com> <4F5CB3D1.4050100@codemonkey.ws> <20120311151246.GL17882@redhat.com> <4F5CC7AC.6080703@codemonkey.ws> <20120312130810.GB20654@otherpad.lan.raisama.net> <20120313145319.GD25451@otherpad.lan.raisama.net> <20120322093244.GE22368@redhat.com> <4F6B5553.20601@codemonkey.ws> <20120322171445.GJ25451@otherpad.lan.raisama.net> <4F6B850D.9000505@codemonkey.ws> <20120325094920.GJ22368@redhat.com> <4F6F15D2.8000504@codemonkey.ws> <4F6F18E4.2040905@redhat.com> <4F6F19AC.1080009@codemonkey.ws> <4F6F1A50.5090502@redhat.com> <4F6F1C32.7090801@codemonkey.ws> <4F6F1ED2.6090301@redhat.com> <4F6F2D7D.70500@codemonkey.ws> <4F6F2FB4.5060405@redhat.com> <4F6F32B8.7050401@codemonkey.ws> In-Reply-To: <4F6F32B8.7050401@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: libvir-list@redhat.com, Jiri Denemark , Eduardo Habkost , Gleb Natapov , qemu-devel@nongnu.org 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? > So what's the mechanism to do this? > >>> C) This model maps to any other type of class factory. Machines will >>> eventually be expressed as a class factory. When we implement this, >>> we would change the default target-x86_64-cpu.cfg to: >>> >>> [system] >>> # Load default CPU definitions >>> readconfig = @DATADIR@/target-x86_64-cpus.cfg >>> # Load default machines >>> readconfig = @DATADIR@/target-x86_64-machines.cfg >>> >>> A machine definition would look like: >>> >>> [machinedef] >>> name = pc-0.15 >>> virtio-blk.class_code = 32 >>> ... >>> >>> Loading a file based on -cpu doesn't generalize well unless we try to >>> load a definition for any possible QOM type to find the class factory >>> for it. I don't think this is a good idea. >> >> Why not load all class factories? Just don't instantiate any objects. > > Unless we have two different config syntaxes, I think it will lead to > a lot of confusion. Having some parts of a config file be parsed and > others not is fairly strange. Parse all of them (and make sure all are class factories). The only real configuration item is that without -nodefconfig, we create a -M pc-1.1 system. Everything else derives from that. > >> 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. -- error compiling committee.c: too many arguments to function