From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJkJg-0002dJ-58 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 04:28:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJkJa-0002VP-2W for qemu-devel@nongnu.org; Thu, 25 Jun 2009 04:28:17 -0400 Received: from [199.232.76.173] (port=60912 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJkJZ-0002V1-PX for qemu-devel@nongnu.org; Thu, 25 Jun 2009 04:28:13 -0400 Received: from mx2.redhat.com ([66.187.237.31]:56604) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJkJZ-0003wZ-B8 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 04:28:13 -0400 Message-ID: <4A43355B.4080406@redhat.com> Date: Thu, 25 Jun 2009 11:29:15 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] KVMs default CPU type References: <20090623162140.GB4379@random.random> <20090624172934.GG14121@shareable.org> <20090624211200.GD15263@random.random> <20090624213944.GD14121@shareable.org> <4A43314E.5050500@amd.com> In-Reply-To: <4A43314E.5050500@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: Andrea Arcangeli , qemu-devel@nongnu.org, kvm@vger.kernel.org On 06/25/2009 11:11 AM, Andre Przywara wrote: > I think we should go away from using qemu64 as a default for KVM. In > my opinion we should target -cpu host as KVM's default, while in > parallel create a -cpu migrate type (still fiddling with the CPUID > details of that), which takes over the qemu64 role of being some kind > of least common denominator. This should be a family 15 CPU (AMD K8 or > Intel P4) with a constant vendor ID (in my experiments Intel showed > less problems with guests). Since 64bit Windows has a whitelist of > known vendor IDs (AMD, Intel on XP, additionally Via on Win7) we > cannot use a bogus vendor, although this should impose the least > problems. -cpu host may have issues other than migration; for example if you upgrade your host processor guests will notice and perhaps trigger a revalidation. It also means every host offers something slightly different to guests, increasing the test matrix. -- error compiling committee.c: too many arguments to function