From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NN7Ld-0006TZ-VN for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:12:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NN7LZ-0006Rs-6G for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:12:33 -0500 Received: from [199.232.76.173] (port=51965 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NN7LY-0006Rj-Ec for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:12:28 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:36958) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NN7LX-0000pz-FF for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:12:28 -0500 Received: by yxe26 with SMTP id 26so6060893yxe.4 for ; Tue, 22 Dec 2009 08:12:25 -0800 (PST) Message-ID: <4B30EFDF.4060202@codemonkey.ws> Date: Tue, 22 Dec 2009 10:12:15 -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> In-Reply-To: <4B2F31B1.6040403@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 12/21/2009 02:28 AM, Dor Laor wrote: > John's new cpu definitions are the exact solution for this issue - all > users, whether using mgmt app or direct qemu (this is no user, this is > a developer/hacker/other, let's do not optimize this case) should use > the various 'real' cpu definitions like -cpu Merom | Nehalem | Penry | > Opteron G1, .... Of course, the tricky part is at what level do you define these names. For instance, do you do just Nehalem, or do you also do Nehalem, Nehalem-EP, Nehalem-EX? Nehalem is really just a code name. Would it be better to use core-i7? 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. 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. 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? Regards, Anthony Liguori