From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. Date: Thu, 21 Jan 2010 12:59:38 -0600 Message-ID: <4B58A41A.5020209@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> <4B588448.7090303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , "Daniel P. Berrange" , "Przywara, Andre" , qemu-devel@nongnu.org, KVM list , Gerd Hoffmann To: john cooper Return-path: Received: from mail-iw0-f196.google.com ([209.85.223.196]:45269 "EHLO mail-iw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753557Ab0AUS7m (ORCPT ); Thu, 21 Jan 2010 13:59:42 -0500 Received: by iwn34 with SMTP id 34so273291iwn.21 for ; Thu, 21 Jan 2010 10:59:41 -0800 (PST) In-Reply-To: <4B588448.7090303@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/21/2010 10:43 AM, john cooper wrote: > Anthony Liguori wrote: > >> On 01/20/2010 07:18 PM, john cooper wrote: >> >>> I can appreciate the concern of wanting to get this >>> as "correct" as possible. >>> >>> >> This is the root of the trouble. At the qemu layer, we try to focus on >> being correct. >> >> Management tools are typically the layer that deals with being "correct". >> >> A good compromise is making things user tunable which means that a >> downstream can make "correctness" decisions without forcing those >> decisions on upstream. >> > Conceptually I agree with such a malleable approach -- actually > I prefer it. I thought however it was too much infrastructure to > foist on the problem just to add a few more models into the mix. > See list for patches. I didn't do the cpu bits but it should be very obvious how to do that now. Regards, Anthony Liguori > The only reservation which comes to mind is that of logistics. > This may ruffle the code some and impact others such as Andre > who seem to have existing patches relative to the current structure. > Anyone have strong objections to this approach before I have a > look at an implementation? > > Thanks, > > -john > > >