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

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

[Eduardo Habkost]

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

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

[Roedel, Joerg]

On Fri, Jun 10, 2011 at 05:36:37PM -0400, Eduardo Habkost wrote:

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

SVM is a special feature. We can't just forward the host-cpuid to the
guest because every SVM feature we provide to the guest needs emulation
in the kernel module. The kernel-module will tell qemu-kvm about its
feature set via the GET_SUPPORTED_CPUID ioctl. So the idea behint -cpu
host and SVM features is that qemu-kvm enables all of them and masks out
everything that is not supported by the kernel module.

Note that the kernel might even emulate features that are not supported
on the host, like the vmcb-clean-bits, so we really need to ask the
kernel what is supported for the guest.

Regards,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

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

[Avi Kivity]

On 06/11/2011 01:40 PM, Roedel, Joerg wrote:
> On Fri, Jun 10, 2011 at 05:36:37PM -0400, Eduardo Habkost wrote:
>
> >  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.
>
> SVM is a special feature. We can't just forward the host-cpuid to the
> guest because every SVM feature we provide to the guest needs emulation
> in the kernel module. The kernel-module will tell qemu-kvm about its
> feature set via the GET_SUPPORTED_CPUID ioctl.

SVM isn't special in this regard.  It's potentially true for any 
feature, and actually true for some of them.

> So the idea behint -cpu
> host and SVM features is that qemu-kvm enables all of them and masks out
> everything that is not supported by the kernel module.

Right (but by whitelisting known features, not blacklisting).

> Note that the kernel might even emulate features that are not supported
> on the host, like the vmcb-clean-bits, so we really need to ask the
> kernel what is supported for the guest.

x2apic is another example.

-- 
error compiling committee.c: too many arguments to function

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