From: Gerd Hoffmann Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. Date: Tue, 26 Jan 2010 09:26:49 +0100 Message-ID: <4B5EA749.1000502@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , "Przywara, Andre" , KVM list , john cooper , qemu-devel@nongnu.org, Chris Wright To: dlaor@redhat.com Return-path: Received: from mx1.redhat.com ([209.132.183.28]:28266 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752009Ab0AZI11 (ORCPT ); Tue, 26 Jan 2010 03:27:27 -0500 In-Reply-To: <4B5E1CB8.3070908@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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