From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVlmT-00023b-NF for qemu-devel@nongnu.org; Sun, 12 Jun 2011 10:36:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QVlmS-0007Lx-JL for qemu-devel@nongnu.org; Sun, 12 Jun 2011 10:36:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVlmS-0007Lp-CO for qemu-devel@nongnu.org; Sun, 12 Jun 2011 10:36:48 -0400 Message-ID: <4DF4CEF9.6070906@redhat.com> Date: Sun, 12 Jun 2011 17:36:41 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20110610213637.GG5205@otherpad.lan.raisama.net> <20110611104019.GD29908@amd.com> In-Reply-To: <20110611104019.GD29908@amd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] semantics of "-cpu host" and "check"/"enforce" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Roedel, Joerg" Cc: Andre Przywara , qemu-devel@nongnu.org, kvm@vger.kernel.org On 06/11/2011 01:40 PM, Roedel, Joerg wrote: > On Fri, Jun 10, 2011 at 05:36:37PM -0400, Eduardo Habkost wrote: > > > We have 3 sets of cpu features that may or may not be included in > > '-cpu host': > > > > A) Features that are supported by the host and that KVM can already > > emulate, or don't need KVM support to be used; > > B) Features that may be not supported by the host but can be emulated by > > KVM (e.g. the SVM features, or x2apic); > > C) Features that are supported by the host but KVM can't emulate. > > Divided in: > > C1) features we can't emulate and we know about it (e.g. dtes64)[1] > > C2) features we possibly can't emulate but we don't even know about it > > (e.g. features added to recent CPUs). > > > > It seems obvious that all the features in group A must always be > > included in '-cpu host', but what about features in the B or C groups? > > > > > > About group B: it looks like we are not being consistent. For example, > > svm_features has every bit enabled when using '-cpu host' even if the > > host doesn't support them; in other cases (e.g. x2apic), it is not > > enabled by '-cpu host' unless the host already supports it. > > SVM is a special feature. We can't just forward the host-cpuid to the > guest because every SVM feature we provide to the guest needs emulation > in the kernel module. The kernel-module will tell qemu-kvm about its > feature set via the GET_SUPPORTED_CPUID ioctl. SVM isn't special in this regard. It's potentially true for any feature, and actually true for some of them. > So the idea behint -cpu > host and SVM features is that qemu-kvm enables all of them and masks out > everything that is not supported by the kernel module. Right (but by whitelisting known features, not blacklisting). > Note that the kernel might even emulate features that are not supported > on the host, like the vmcb-clean-bits, so we really need to ask the > kernel what is supported for the guest. x2apic is another example. -- error compiling committee.c: too many arguments to function