From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [PATCH 2/2] qemu-kvm: Add svm cpuid features Date: Sun, 12 Sep 2010 10:01:28 +0200 Message-ID: <4C8C88D8.90705@redhat.com> References: <1284133120-19453-1-git-send-email-joerg.roedel@amd.com> <1284133120-19453-3-git-send-email-joerg.roedel@amd.com> <20100911142018.GA680@8bytes.org> <4C8C6DC3.9030009@redhat.com> <80A3FA90-7AF7-4733-B416-5FF21BCC877A@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joerg Roedel , Joerg Roedel , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:64471 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751958Ab0ILIBl (ORCPT ); Sun, 12 Sep 2010 04:01:41 -0400 In-Reply-To: <80A3FA90-7AF7-4733-B416-5FF21BCC877A@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 09/12/2010 09:16 AM, Alexander Graf wrote: >>> >>> Depends on which Phenom you have. A Phenom II has NRIPSAVE but the old >>> Phenoms don't have it. For the SVM features it is not that important >>> what the host hardware supports but what KVM can emulate. VMCBCLEAN can >>> be emulated without supporting it in the host for example. >> Well, let's have a phenom2 type for those new features (and any other features the phenom 2 has). What's the point of using the name of existing hardware if it doesn't match that hardware? > Isn't that what cpu=host is there for? I don't want to see cpu type cluttering like we have it on ppc. I added the core2duo type for Mac OS X guests for which those are basically the oldest supported CPUs. -cpu host is to all supported features into your guest. -cpu phenom is to pretend you are running on a phenom cpu. This is useful for a migration farm for which the greatest common denominator is a phenom. Those are separate use cases. > For the Phenom type, I honestly don't remember why, but there was also a good reason to add it. In fact, I use it today to have nested virt without -cpu host on hardware that's too new for my guests. Curious, what guests balk at modern hardware but are fine with phenom? > Either way, I don't think we need a phenom2 type. The features additional are minor enough to not really matter and all use cases I can come up with require either -cpu host (local virt) or -cpu phenom (migration). I'm fine with this (or with adding phenom2). But don't make phenom contain flags that real phenoms don't have. -- error compiling committee.c: too many arguments to function