Re: [Qemu-devel] semantics of "-cpu host" and "check"/"enforce"

[Avi Kivity]

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