On 06/11/2011 12:36 AM, Eduardo Habkost wrote:
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
We have 3 sets of cpu features that may or may not be included in
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.
C1) features we can't emulate and we know about it (e.g. dtes64)
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
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
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,
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.
 And 3dnow? Why is 3dnow always disabled on qemu-kvm.git/master, at
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
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html