From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSJTk-0005NF-PB for qemu-devel@nongnu.org; Tue, 05 Jan 2010 19:10:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSJTg-0005L6-10 for qemu-devel@nongnu.org; Tue, 05 Jan 2010 19:10:24 -0500 Received: from [199.232.76.173] (port=46556 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSJTf-0005L1-Jy for qemu-devel@nongnu.org; Tue, 05 Jan 2010 19:10:19 -0500 Received: from mail-qy0-f194.google.com ([209.85.221.194]:53776) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSJTf-00048D-0T for qemu-devel@nongnu.org; Tue, 05 Jan 2010 19:10:19 -0500 Received: by qyk32 with SMTP id 32so6852687qyk.4 for ; Tue, 05 Jan 2010 16:10:17 -0800 (PST) Message-ID: <4B43D4E2.9050102@codemonkey.ws> Date: Tue, 05 Jan 2010 18:10:10 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <4B2DF334.6030208@redhat.com> <20091220155101.GB31257@redhat.com> <4B2E49E5.6050709@redhat.com> <20091220165612.GC31257@redhat.com> <20091220171822.GD31257@redhat.com> <20091220172341.GB21163@redhat.com> <2162E312-0110-42E1-A391-D75A6F013554@suse.de> <20091220173702.GC21163@redhat.com> <4B2E660F.1050703@codemonkey.ws> <20091221074355.GU4490@redhat.com> <4B2F31B1.6040403@redhat.com> <4B30EFDF.4060202@codemonkey.ws> <4B31F1BA.10005@redhat.com> In-Reply-To: <4B31F1BA.10005@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: Avi Kivity Cc: Gleb Natapov , "Michael S. Tsirkin" , John Cooper , dlaor@redhat.com, qemu-devel@nongnu.org, Alexander Graf On 12/23/2009 04:32 AM, Avi Kivity wrote: > On 12/22/2009 06:12 PM, Anthony Liguori wrote: >> >> I think the only two Fully Correct approachs are to support a very >> specific CPU (e.g. Xeon-X5270) or provide the ability to individually >> tweak cpu flags. > > Yes. By a curious coincidence these are what the hardware vendors > define (unlike compat classes etc.). Whenever possible, steal from what the hardware vendors do :-) >> The notion of compatibility classes should probably be left to >> management tools. We can make it a lot easier for them though by >> supporting turning point CPU models. > > Agreed. > >> >> For instance, Xeon-X5570 should be a least common denominator for >> Nehalem processors. It's probably better for users too. It's easier >> for them to answer "do I have anything older than a Xeon-X5570" than >> to ask "do I have any Woodcrest class processors". >> >> I encounter this confusion a lot. I usually ask people whether they >> have a Nehalem processor when debugging something and their response >> is always, I have a Xeon-XYZ, is that Nehalem? > > This is complicated by the fact that processors don't have > straight-line development, and that marketing names don't correspond > to anything. For example Xeon can be any of the Pentium 4, Core, Core > 2, and Nehalem (and perhaps other) microachitectures. A newer Xeon is > often introduced with an older core (usually for larger machines) than > previously existing Xeons. Typically, there is at least a little sanity naming for these cases. For instance, any Xeon W35xx should have the same features. A Xeon W55xx may be different. It's not going to be easy to include every possible model. It's a hard problem for management tools too. The thing is, I imagine most management tools are going to cat /proc/cpuinfo to get what the processor is and that's going to be a Xeon YYXXXX type name so I really believe that's the thing that makes sense to expose in QEMU. Maybe we could name models like IntelXeonW35xx. Clever use of the preprocessor will make this effort much, much saner. Also, we really need some sort of human readable document that explains the differences between processor classes and makes recommendations about what management tools should take into consideration. Regards, Anthony Liguori