From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeFFD-00025A-I8 for qemu-devel@nongnu.org; Thu, 20 Aug 2009 17:32:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeFF7-000200-VY for qemu-devel@nongnu.org; Thu, 20 Aug 2009 17:32:26 -0400 Received: from [199.232.76.173] (port=56362 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeFF7-0001zu-Pc for qemu-devel@nongnu.org; Thu, 20 Aug 2009 17:32:21 -0400 Received: from va3ehsobe003.messaging.microsoft.com ([216.32.180.13]:51950 helo=VA3EHSOBE003.bigfish.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1MeFF7-0003V0-Dx for qemu-devel@nongnu.org; Thu, 20 Aug 2009 17:32:21 -0400 Message-ID: <4A8DC18B.6070500@amd.com> Date: Thu, 20 Aug 2009 23:35:07 +0200 From: Andre Przywara MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/3] push CPUID level to 4 to allow Intel multicore decoding References: <1250689362-11067-1-git-send-email-andre.przywara@amd.com> <1250689362-11067-3-git-send-email-andre.przywara@amd.com> <4A8D2037.4000002@redhat.com> <4A8D2722.2000905@amd.com> <20090820193023.GD6066@shareable.org> In-Reply-To: <20090820193023.GD6066@shareable.org> 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: Jamie Lokier Cc: Avi Kivity , qemu-devel@nongnu.org Jamie Lokier wrote: > Andre Przywara wrote: >> The other option would be to push the level only to four if we use more >> than one thread or core. >> >> In my research it turned out that Intel pushed the level beyond 4 >> with Pentium4 Prescott (probably with the introduction of real dual >> core chips to differentiate threads and cores), so this is quite >> some time ago. > > Pentium 4 wasn't that long ago, from a point of view of running legacy > guests. Well, but long enough to get those software issues ruled out. If any serious OS would have had problems, somebody would have noticed and fixed it. > I see quite a lot of code in Linux (to pick an example - presumably > also other OSes) which checks for things by looking at model and > family number, so I wonder if it's wise to depart a long way from > CPUIDs which resemble real hardware which has existed. Yeah, but most of the stuff Linux checks are bugs and workarounds, so I am not 100% sure whether it's an advantage. We should be careful with adjusting the working default QEMU/KVM has right now. > We've already seen a problem along these lines, which was the x86 > CPUID_SEP feature not getting used properly, but that was quite well > hidden, only affecting one application (Skype) on Windows. > > Could it make more sense to, in effect, upgrade the default CPUID > to Pentium 4 (instead of Pentium Pro) when cores > 1? OK, OK, I will finally send this patch out (following in another mail). This is a kvm64 CPU (which should become the new KVM's default, if it proves to work well). It looks like a P4 Prescott, that seems to be a good base, since it has a decent base line of features and is among the first CPUs which are supported by KVM. If someone has such a real beast (best would be a Pentium 4 662 or other Prescotts with x86_64, HT and VT-x), I would love to see a complete CPUID dump (including the 0000_0004 subleafs, which x86info omits). Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 488-3567-12 ----to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632