qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eduardo Habkost
Subject: [Qemu-devel] semantics of "-cpu host" and "check"/"enforce"
Date: Fri, 10 Jun 2011 18:36:37 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

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"?)


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?


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); 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?


[1] And 3dnow? Why is 3dnow always disabled on qemu-kvm.git/master, at
    cpu_x86_cpuid()?

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]