From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZXWV-0002ug-MM for qemu-devel@nongnu.org; Mon, 25 Jan 2010 17:35:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZXWP-0002rw-62 for qemu-devel@nongnu.org; Mon, 25 Jan 2010 17:35:06 -0500 Received: from [199.232.76.173] (port=59882 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZXWO-0002rn-R0 for qemu-devel@nongnu.org; Mon, 25 Jan 2010 17:35:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60513) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZXWO-0006VC-Ff for qemu-devel@nongnu.org; Mon, 25 Jan 2010 17:35:00 -0500 Message-ID: <4B5E1CB8.3070908@redhat.com> Date: Tue, 26 Jan 2010 00:35:36 +0200 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. References: <4B549016.6090501@redhat.com> <4B560A88.9@codemonkey.ws> <20100119200349.GG3204@sequoia.sous-sol.org> <4B563144.9030803@codemonkey.ws> <4B576311.3030906@redhat.com> <20100120202634.GA20754@redhat.com> <20100121002509.GM3204@sequoia.sous-sol.org> <4B57AB66.30802@redhat.com> <4B586D4A.50207@codemonkey.ws> <4B5D5F84.4040507@redhat.com> <4B5DA8DE.3040600@codemonkey.ws> In-Reply-To: <4B5DA8DE.3040600@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Przywara, Andre" , KVM list , john cooper , qemu-devel@nongnu.org, Chris Wright , Gerd Hoffmann On 01/25/2010 04:21 PM, Anthony Liguori wrote: > On 01/25/2010 03:08 AM, Dor Laor wrote: >>> qemu-config.[ch], taking a new command line that parses the argument via >>> QemuOpts, then passing the parsed options to a target-specific function >>> that then builds the table of supported cpus. >> It should just be a matter of adding qemu_cpudefs_opts to >> >> Isn't the outcome of John's patches and these configs will be exactly >> the same? Since these cpu models won't ever change, there is no reason >> why not to hard code them. Adding configs or command lines is a good >> idea but it is more friendlier to have basic support to the common cpus. >> This is why qemu today offers: -cpu ? >> x86 qemu64 >> x86 phenom >> x86 core2duo >> x86 kvm64 >> x86 qemu32 >> x86 coreduo >> x86 486 >> x86 pentium >> x86 pentium2 >> x86 pentium3 >> x86 athlon >> x86 n270 >> >> So bottom line, my point is to have John's base + your configs. We >> need to keep also the check verb and the migration support for sending >> those. >> >> btw: IMO we should deal with this complexity ourselves and save 99.9% >> of the users the need to define such models, don't ask this from a >> java programmer, he is running on a JVM :-) > > I'm suggesting John's base should be implemented as a default config > that gets installed by default in QEMU. The point is that a smart user > (or a downstream) can modify this to suite their needs more appropriately. > > Another way to look at this is that implementing a somewhat arbitrary > policy within QEMU's .c files is something we should try to avoid. > Implementing arbitrary policy in our default config file is a fine thing > to do. Default configs are suggested configurations that are modifiable > by a user. Something baked into QEMU is something that ought to work for If we get the models right, users and mgmt stacks won't need to define them. It seems like almost impossible task for us, mgmt stack/users won't do a better job, the opposite I guess. The configs are great, I have no argument against them, my case is that if we can pin down some definitions, its better live in the code, like the above models. It might even help to get the same cpus across the various vendors, otherwise we might end up with IBM's core2duo, RH's core2duo, Suse's,.. > everyone in all circumstances. > > Regards, > > Anthony Liguori > >