From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MeDLF-00038I-GM
	for qemu-devel@nongnu.org; Thu, 20 Aug 2009 15:30:33 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MeDLA-0002zo-0l
	for qemu-devel@nongnu.org; Thu, 20 Aug 2009 15:30:32 -0400
Received: from [199.232.76.173] (port=55677 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MeDL9-0002zb-PR
	for qemu-devel@nongnu.org; Thu, 20 Aug 2009 15:30:27 -0400
Received: from mail2.shareable.org ([80.68.89.115]:38260)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1MeDL9-0008GN-9m
	for qemu-devel@nongnu.org; Thu, 20 Aug 2009 15:30:27 -0400
Date: Thu, 20 Aug 2009 20:30:23 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH 2/3] push CPUID level to 4 to allow Intel
	multicore decoding
Message-ID: <20090820193023.GD6066@shareable.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A8D2722.2000905@amd.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Andre Przywara <andre.przywara@amd.com>
Cc: Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org

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.

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.

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?

-- Jamie