From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SC5uj-00072K-St for qemu-devel@nongnu.org; Mon, 26 Mar 2012 05:08:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SC5ud-0004NC-Cc for qemu-devel@nongnu.org; Mon, 26 Mar 2012 05:08:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SC5ud-0004Mw-4J for qemu-devel@nongnu.org; Mon, 26 Mar 2012 05:08:27 -0400 Message-ID: <4F703200.4050008@redhat.com> Date: Mon, 26 Mar 2012 11:08:16 +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> <4F6F36C7.8010206@redhat.com> <4F6F3941.6040800@codemonkey.ws> <4F6F3C5D.7040802@redhat.com> <4F6F5FB8.2040505@codemonkey.ws> In-Reply-To: <4F6F5FB8.2040505@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 08:11 PM, Anthony Liguori wrote: > >> I don't think -nodefconfig (as defined) is usable, since there is no way >> for the user to tell what it means short of reading those files. > > *if the user doesn't know specifics about this QEMU version. > > You make the assumption that all users are going to throw arbitrary > options at arbitrary QEMU versions. That's certainly an important > use-case but it's not the only one. If a Fedora user is using qemu, then their qemu version will change every six months. Their options are to update their scripts/management tool in step, or not have their management tool use -nodefconfig. The same holds for anyone using qemu from upstream, since that's approximately the qemu release cycle. > >> -no-user-config is usable, I think it needs also to mean that qemu >> without -M/-cpu/-m options will error out? > > You're confusing -nodefaults (or something stronger than -nodefaults) > with -no-user-config. > Right. > Yes, the distinctions are confusing. It's not all fixable tomorrow. > If we take my config refactoring series, we can get 90% of the way > there soon but Paolo has a more thorough refactoring.. > >>>> "#define westmere blah" is not configuration, otherwise the meaning of >>>> configuration will drift over time. >>>> >>>> -cpu blah is, of course. >>> >>> It's the same mechanism, but the above would create two classes of >>> default configuration files and then it becomes a question of how >>> they're used. >> >> Confused. > > We don't have a formal concept of -read-definition-config and > -read-configuration-config > > There's no easy or obvious way to create such a concept either nor do > I think the distinction is meaningful to users. Definition files should be invisible to users. They're part of the implementation. If we have a file that says pc-1.1 = piix + cirrus + memory(128) + ... then it's nobody's business if it's in a text file or a .c file. Of course it's nice to allow users to load their own definition files, but that's strictly a convenience. >> Exactly. The types are no different, so there's no reason to >> discriminate against types that happen to live in qemu-provided data >> files vs. qemu code. They aren't instantiated, so we lose nothing by >> creating the factories (just so long as the factories aren't >> mass-producing objects). > > > At some point, I'd like to have type modules that are shared objects. > I'd like QEMU to start with almost no builtin types and allow the user > to configure which modules get loaded. > > In the long term, I'd like QEMU to be a small, robust core with the > vast majority of code relegated to modules with the user ultimately in > control of module loading. > > Yes, I'd want some module autoloading system but there should always > be a way to launch QEMU without loading any modules and then load a > very specific set of modules (as defined by the user). > > You can imagine this being useful for something like Common Criteria > certifications. Okay. > It's obviously defined for a given release, just not defined long term. > >> If I see something like -nodefconfig, I assume it will create a bare >> bones guest that will not depend on any qemu defaults and will be stable >> across releases. > > That's not even close to what -nodefconfig is. That's pretty much > what -nodefaults is but -nodefaults has also had a fluid definition > historically. Okay. Let's just make sure to document -nodefconfig as version specific and -nodefaults as the stable way to create a bare bones guest (and define exactly what that means). -- error compiling committee.c: too many arguments to function