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 16:36:58 +0200 Message-ID: <4C8CE58A.80806@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> <4C8C88D8.90705@redhat.com> <20100912143049.GE680@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Joerg Roedel , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50991 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753040Ab0ILOhM (ORCPT ); Sun, 12 Sep 2010 10:37:12 -0400 In-Reply-To: <20100912143049.GE680@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: On 09/12/2010 04:30 PM, Joerg Roedel wrote: > >>> 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. > How about features that are not supported by the hardware but can be > supported in emulation? The VMCBCLEAN feature is one of those which > makes a lot of sense to reduce the emulated world-switch times. I guess > its ok to enable those with -cpu host? > > It's a good question. We do that with x2apic, so yes. Userspace can do four things with KVM_GET_SUPPORTED_CPUID: - feed it right back to KVM_SET_CPUID2, getting maximum features and hopefully performance - use it to mask the real cpuid which it fetches directly, getting something as similar as possible to the host - use it to mask a predefined cpu type, getting something as similar as possible to that cpu type - use it to verify that a predefined cpu type is supported, getting somthing exactly the same as that cpu type -cpu host is the first option. If the need comes for the second option, we can provide it. I'll note that KVM_GET_SUPPORTED_CPUID can return values not present in the host cpuid in the documentation. -- error compiling committee.c: too many arguments to function