From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Me5TM-00074s-0A for qemu-devel@nongnu.org; Thu, 20 Aug 2009 07:06:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Me5TH-00073A-Sp for qemu-devel@nongnu.org; Thu, 20 Aug 2009 07:06:23 -0400 Received: from [199.232.76.173] (port=49430 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Me5TH-000734-Fe for qemu-devel@nongnu.org; Thu, 20 Aug 2009 07:06:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48870) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Me5TH-0006mA-5w for qemu-devel@nongnu.org; Thu, 20 Aug 2009 07:06:19 -0400 Message-ID: <4A8D2E1E.2040608@redhat.com> Date: Thu, 20 Aug 2009 14:06:06 +0300 From: Avi Kivity 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> In-Reply-To: <4A8D2722.2000905@amd.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: Andre Przywara Cc: qemu-devel@nongnu.org On 08/20/2009 01:36 PM, Andre Przywara wrote: > Avi Kivity wrote: >> On 08/19/2009 04:42 PM, Andre Przywara wrote: >>> Intel CPUs store the number of cores in CPUID leaf 4. So push >>> the maxleaf value to 4 to allow the guests access to this leaf. >> >> There's a slight compatibility risk here. If a guest has broken >> handling for cpuid level 4, then upgrading qemu would cause it to >> behave differently. >> >> I don't think that's an issue for this patch, just highlighting the >> need for a systematic treatment of backward compatibility. > > If you have real headaches about it, I have two options: It's really an imaginary headache. > > What about allowing level to be specified at -cpu command line? This > would allow users to say -cpu qemu64,level=2 if they experience > problems. The default would stay at level 4. I think this is the best option. > 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. So I doubt that there are serious issues out there. I only pointed this out as an example of a new feature that has an effect even if it is not used, something we should beware of. > The only problem I can think of is that the advertised cache topology > is somehow bogus and could confuse OSes. So long as it's smaller than contemporary caches we should be fine. btw, does -cpu host use the host cpu cache information? -- error compiling committee.c: too many arguments to function