From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBouV-0004u0-SW for qemu-devel@nongnu.org; Sun, 25 Mar 2012 10:59:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBouT-000366-MX for qemu-devel@nongnu.org; Sun, 25 Mar 2012 10:59:11 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:52014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBouT-000362-Fv for qemu-devel@nongnu.org; Sun, 25 Mar 2012 10:59:09 -0400 Received: by obbwd20 with SMTP id wd20so4796860obb.4 for ; Sun, 25 Mar 2012 07:59:07 -0700 (PDT) Message-ID: <4F6F32B8.7050401@codemonkey.ws> Date: Sun, 25 Mar 2012 09:59:04 -0500 From: Anthony Liguori 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> In-Reply-To: <4F6F2FB4.5060405@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Avi Kivity Cc: libvir-list@redhat.com, Jiri Denemark , Eduardo Habkost , Gleb Natapov , qemu-devel@nongnu.org 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... > Configuring = modifying current instance > >> >>> target-x86_64-cpus.cfg does not configure qemu for anything, it's merely >>> the equivalent of >>> >>> #define westmere (x86_def_t) { ... } >>> #define nehalem (x86_def_t) { ... } >>> #define bulldozer (x86_def_t) { ... } // for PC >>> >>> so it should be read at each invocation. On the other hand, pc.cfg and >>> westmere.cfg (as used previously) are shorthand for >>> >>> machine = (QEMUMachine) { ... }; >>> cpu = (x86_def_t) { ... }; >>> >>> so they should only be read if requested explicitly (or indirectly). >> >> This doesn't make a lot of sense to me. Here's what I'm proposing: >> >> 1) QEMU would have a target-x86_64-cpu.cfg.in that is installed by >> default in /etc/qemu. It would contain: >> >> [system] >> # Load default CPU definitions >> readconfig = @DATADIR@/target-x86_64-cpus.cfg >> >> 2) target-x86_64-cpus.cfg would be installed to @DATADIR@ and would >> contain: >> >> [cpudef] >> name = "Westmere" >> ... >> >> This has the following properties: >> >> A) QEMU has no builtin notion of CPU definitions. It just has a "cpu >> factory". -cpudef will create a new class called Westmere that can >> then be enumerated through qom-type-list and created via qom-create. >> >> 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". > 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? 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. > Otherwise, the meaning of -nodefconfig changes as more stuff is moved > out of .c and into .cfg. What's the problem with this? >>>>> The reasoning is, loading target-x86_64-cpus.cfg does not alter the >>>>> current instance's configuration, so reading it doesn't violate >>>>> -nodefconfig. >>>> >>>> I think we have a different view of what -nodefconfig does. >>>> >>>> We have a couple options today: >>>> >>>> -nodefconfig >>>> >>>> Don't read the default configuration files. By default, we read >>>> /etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg >>>> >>> >>> The latter seems meaningless to avoid reading. It's just a set of >>> #defines, what do you get by not reading it? >> >> 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.. >> >>>> -nodefaults >>>> >>>> Don't create default devices. >>>> >>>> -vga none >>>> >>>> Don't create the default VGA device (not covered by -nodefaults). >>>> >>>> With these two options, the semantics you get an absolutely >>>> minimalistic instance of QEMU. Tools like libguestfs really want to >>>> create the simplest guest and do the least amount of processing so the >>>> guest runs as fast as possible. >>>> >>>> It does suck a lot that this isn't a single option. I would much >>>> prefer -nodefaults to be implied by -nodefconfig. Likewise, I would >>>> prefer that -nodefaults implied -vga none. >>> >>> I don't have a qemu.cfg so can't comment on it, but in what way does >>> reading target-x86_64.cfg affect the current instance (that is, why is >>> -nodefconfig needed over -nodefaults -vga look-at-the-previous-option?) >> >> It depends on what the user configures it to do. > > How? > > 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. Regards, Anthony Liguori