From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: semantics of "-cpu host" and "check"/"enforce" Date: Sun, 12 Jun 2011 17:48:31 +0300 Message-ID: <4DF4D1BF.5040108@redhat.com> References: <20110610213637.GG5205@otherpad.lan.raisama.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: qemu-devel@nongnu.org, kvm@vger.kernel.org, Andre Przywara , Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:21713 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751254Ab1FLOsi (ORCPT ); Sun, 12 Jun 2011 10:48:38 -0400 In-Reply-To: <20110610213637.GG5205@otherpad.lan.raisama.net> Sender: kvm-owner@vger.kernel.org List-ID: On 06/11/2011 12:36 AM, Eduardo Habkost wrote: > Hi, > > While checking the cpu model code, I don't think I understand fully what > is supposed to be the right semantics for '-cpu host' on qemu-kvm, and > what exactly we are aiming to. > > Maybe this was already discussed before, but I failed to find any > additional information except for the original '-cpu host' patch > submission. > > 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. > > Shouldn't we aim for consistency here and choose one of both approaches? > Maybe we want two different model names or options, to differentiate (A) > and (A+B)? (maybe something like "host" and "host,+all"?) We should choose A+B always, since that's what's supposed to give the best performance. By a lucky coincidence, A+B is the output of KVM_GET_SUPPORTED_CPUID. > About group C: If the C group is not empty and 'enforce' is set in the > command-line, should we try to enable the feature and consider the > missing feature a failure condition, or simply avoid enabling the > feature? No, we should fail. But we should allow the user to set a bit even if kvm doesn't think it supports it (but it should be an explicit request). > > Current semantics of '-cpu host' seems to be: A + all svm features. That > means that only part of B is included (all emulated svm features are in, > but x2apic is out); '-cpu host' should mean the output of KVM_GET_SUPPORTED_CPUID, no more, no less. > group C seems to be excluded entirely (by > whitelisting in the kvm kernel code), but the disabled features don't > trigger "enforce" errors. Is that correct? If so, that's a bug. > [1] And 3dnow? Why is 3dnow always disabled on qemu-kvm.git/master, at > cpu_x86_cpuid()? It's likely due to guests using 3dnow to write to the framebuffer, while kvm doesn't emulate instructions (so, a kvm bug work around). -- error compiling committee.c: too many arguments to function