From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnvV-0002QK-Ig for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:56:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBnvT-0000S5-Hi for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:56:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBnvT-0000Rw-9Z for qemu-devel@nongnu.org; Sun, 25 Mar 2012 09:56:07 -0400 Message-ID: <4F6F1ED2.6090301@redhat.com> Date: Sun, 25 Mar 2012 15:34:10 +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> In-Reply-To: <4F6F1C32.7090801@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 03:22 PM, Anthony Liguori wrote: >>>> In that case >>>> >>>> qemu -cpu westmere >>>> >>>> is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg. >>> >>> >>> This is not a bad suggestion, although it would make -cpu ? a bit >>> awkward. Do you see an advantage to this over having >>> /usr/share/qemu/target-x86_64-cpus.cfg that's read early on? >> >> Nope. As long as qemu -nodefconfig -cpu westmere works, I'm happy. > > > Why? What's wrong with: > > qemu -nodefconfig -readconfig > /usr/share/qemu/cpus/target-x86_64-cpus.cfg \ > -cpu westmere > > And if that's not okay, would: > > qemu -nodefconfig -nocpudefconfig -cpu Westmere > > Not working be a problem? Apart from the command line length, it confuses configuration with definition. 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). > >> 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? > -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?) > >>>>> files be read by default or just treated as additional configuration >>>>> files. >>>> >>>> If they're read as soon as they're referenced, what's the difference? >>> I think the thread has reduced to: should /usr/share configuration >>> >>> I suspect libvirt would not be happy with reading configuration files >>> on demand.. >> >> Why not? > > It implies a bunch of SELinux labeling to make sVirt work. libvirt > tries very hard to avoid having QEMU read *any* files at all when it > starts up. The /usr/share/qemu files should be statically labelled to allow qemu to read them, so we can push more code into data files. -- error compiling committee.c: too many arguments to function