From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSXdA-0005IC-RK for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:17:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSXd5-0005FA-F1 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:17:03 -0500 Received: from [199.232.76.173] (port=34519 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSXd5-0005F2-7r for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:16:59 -0500 Received: from mail-fx0-f222.google.com ([209.85.220.222]:41079) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSXd4-0003Tc-Nc for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:16:58 -0500 Received: by fxm22 with SMTP id 22so19944361fxm.2 for ; Wed, 06 Jan 2010 07:16:57 -0800 (PST) Message-ID: <4B44A965.9040300@codemonkey.ws> Date: Wed, 06 Jan 2010 09:16:53 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <4B30EFDF.4060202@codemonkey.ws> <4B31F1BA.10005@redhat.com> <4B43D4E2.9050102@codemonkey.ws> <4B4402B1.1030605@redhat.com> <4B448F36.8030605@codemonkey.ws> <4B449467.4070606@redhat.com> <4B4494FC.1080907@codemonkey.ws> <4B449608.7040102@redhat.com> <4B4496E9.2030201@redhat.com> <20100106142231.GF2248@redhat.com> <4B449EE7.4050401@redhat.com> <4B44A2C6.4050504@redhat.com> In-Reply-To: <4B44A2C6.4050504@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Gleb Natapov , "Michael S. Tsirkin" , John Cooper , qemu-devel@nongnu.org, Alexander Graf , Avi Kivity On 01/06/2010 08:48 AM, Dor Laor wrote: > On 01/06/2010 04:32 PM, Avi Kivity wrote: >> On 01/06/2010 04:22 PM, Michael S. Tsirkin wrote: >>>> We can probably default -enable-kvm to -cpu host, as long as we >>>> explain >>>> very carefully that if users wish to preserve cpu features across >>>> upgrades, they can't depend on the default. >>> Hardware upgrades or software upgrades? >> >> Yes. >> > > I just want to remind all the the main motivation for using -cpu > realModelThatWasOnceShiped is to provide correct cpu emulation for the > guest. Using a random qemu|kvm64+flag1-flag2 might really cause > trouble for the guest OS or guest apps. > > On top of -cpu nehalem we can always add fancy features like x2apic, etc. I think it boils down to, how are people going to use this. For individuals, code names like Nehalem are too obscure. From my own personal experience, even power users often have no clue whether there processor is a Nehalem or not. For management tools, Nehalem is a somewhat imprecise target because it covers a wide range of potential processors. In general, I think what we really need to do is simplify the process of going from, here's the output of /proc/cpuinfo for a 100 nodes, what do I need to pass to qemu so that migration always works for these systems. I don't think -cpu nehalem really helps with that problem. -cpu none helps a bit, but I hope we can find something nicer. Regards, Anthony Liguori