From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZglo-00029S-0z for qemu-devel@nongnu.org; Tue, 26 Jan 2010 03:27:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZglg-00027s-Mw for qemu-devel@nongnu.org; Tue, 26 Jan 2010 03:27:29 -0500 Received: from [199.232.76.173] (port=57535 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZglf-00027f-5D for qemu-devel@nongnu.org; Tue, 26 Jan 2010 03:27:23 -0500 Received: from mx20.gnu.org ([199.232.41.8]:42812) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NZgle-0006h1-Ea for qemu-devel@nongnu.org; Tue, 26 Jan 2010 03:27:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZgld-0003IL-72 for qemu-devel@nongnu.org; Tue, 26 Jan 2010 03:27:21 -0500 Message-ID: <4B5EA749.1000502@redhat.com> Date: Tue, 26 Jan 2010 09:26:49 +0100 From: Gerd Hoffmann 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> <4B5E1CB8.3070908@redhat.com> In-Reply-To: <4B5E1CB8.3070908@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 On 01/25/10 23:35, Dor Laor wrote: > On 01/25/2010 04:21 PM, Anthony Liguori wrote: >> 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,.. I agree. When looking at this thread and config file idea it feels a bit like "we have a hard time to agree on some sensible default cpu types, so lets make this configurable so we don't have to". Which is a bad thing IMHO. cheers, Gerd