From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZPop-0005Iy-2Z for qemu-devel@nongnu.org; Mon, 25 Jan 2010 09:21:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZPoj-0005GQ-Qo for qemu-devel@nongnu.org; Mon, 25 Jan 2010 09:21:30 -0500 Received: from [199.232.76.173] (port=36170 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZPoj-0005GJ-ME for qemu-devel@nongnu.org; Mon, 25 Jan 2010 09:21:25 -0500 Received: from mail-iw0-f188.google.com ([209.85.223.188]:40554) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZPoj-00074Z-Fo for qemu-devel@nongnu.org; Mon, 25 Jan 2010 09:21:25 -0500 Received: by iwn26 with SMTP id 26so3342142iwn.14 for ; Mon, 25 Jan 2010 06:21:24 -0800 (PST) Message-ID: <4B5DA8DE.3040600@codemonkey.ws> Date: Mon, 25 Jan 2010 08:21:18 -0600 From: Anthony Liguori 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> In-Reply-To: <4B5D5F84.4040507@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: "Przywara, Andre" , KVM list , john cooper , qemu-devel@nongnu.org, Chris Wright , Gerd Hoffmann 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 everyone in all circumstances. Regards, Anthony Liguori