From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVlxv-0003g2-J6 for qemu-devel@nongnu.org; Sun, 12 Jun 2011 10:48:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QVlxu-0000Rm-K6 for qemu-devel@nongnu.org; Sun, 12 Jun 2011 10:48:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVlxu-0000Rf-Ae for qemu-devel@nongnu.org; Sun, 12 Jun 2011 10:48:38 -0400 Message-ID: <4DF4D1BF.5040108@redhat.com> Date: Sun, 12 Jun 2011 17:48:31 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20110610213637.GG5205@otherpad.lan.raisama.net> In-Reply-To: <20110610213637.GG5205@otherpad.lan.raisama.net> 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: qemu-devel@nongnu.org, kvm@vger.kernel.org, Andre Przywara , Joerg Roedel 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