From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. Date: Tue, 26 Jan 2010 06:54:04 -0600 Message-ID: <4B5EE5EC.4020006@codemonkey.ws> 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> <4B5EA749.1000502@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dlaor@redhat.com, "Przywara, Andre" , KVM list , john cooper , qemu-devel@nongnu.org, Chris Wright To: Gerd Hoffmann Return-path: Received: from mail-iw0-f173.google.com ([209.85.223.173]:35893 "EHLO mail-iw0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750734Ab0AZMyJ (ORCPT ); Tue, 26 Jan 2010 07:54:09 -0500 Received: by iwn3 with SMTP id 3so324832iwn.19 for ; Tue, 26 Jan 2010 04:54:07 -0800 (PST) In-Reply-To: <4B5EA749.1000502@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/26/2010 02:26 AM, Gerd Hoffmann wrote: > 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. There's no sensible default. If a user only has Nehalem-EX class processors and Westmeres, why would they want to limit themselves to just Nehalem? For an organization that already uses and understand the VMware grouping, is it wrong for them to want to just use VMware-style grouping? This feature is purely data driven. There is no code involved. Any time a feature is purely data driven and there isn't a clear right and wrong solution, a configuration file is a natural solution IMHO. I think the only real question is whether it belongs in the default config or a dedicated configuration file but honestly that's just a statement of convention. Regards, Anthony Liguori > cheers, > Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZkvt-0005DY-B3 for qemu-devel@nongnu.org; Tue, 26 Jan 2010 07:54:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZkvo-00056w-KU for qemu-devel@nongnu.org; Tue, 26 Jan 2010 07:54:12 -0500 Received: from [199.232.76.173] (port=51596 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZkvo-00056h-FE for qemu-devel@nongnu.org; Tue, 26 Jan 2010 07:54:08 -0500 Received: from mail-iw0-f188.google.com ([209.85.223.188]:60121) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZkvn-0004je-UZ for qemu-devel@nongnu.org; Tue, 26 Jan 2010 07:54:08 -0500 Received: by iwn26 with SMTP id 26so4681156iwn.14 for ; Tue, 26 Jan 2010 04:54:07 -0800 (PST) Message-ID: <4B5EE5EC.4020006@codemonkey.ws> Date: Tue, 26 Jan 2010 06:54:04 -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> <4B5DA8DE.3040600@codemonkey.ws> <4B5E1CB8.3070908@redhat.com> <4B5EA749.1000502@redhat.com> In-Reply-To: <4B5EA749.1000502@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: Gerd Hoffmann Cc: "Przywara, Andre" , KVM list , john cooper , dlaor@redhat.com, qemu-devel@nongnu.org, Chris Wright On 01/26/2010 02:26 AM, Gerd Hoffmann wrote: > 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. There's no sensible default. If a user only has Nehalem-EX class processors and Westmeres, why would they want to limit themselves to just Nehalem? For an organization that already uses and understand the VMware grouping, is it wrong for them to want to just use VMware-style grouping? This feature is purely data driven. There is no code involved. Any time a feature is purely data driven and there isn't a clear right and wrong solution, a configuration file is a natural solution IMHO. I think the only real question is whether it belongs in the default config or a dedicated configuration file but honestly that's just a statement of convention. Regards, Anthony Liguori > cheers, > Gerd