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
'-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

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

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

Reply via email to