Bug 1062111

I see that rhev-h is referring to /usr/share/libvirt/cpu_map.xml to determine the type of CPU based on the flags that are supported on the processor. 

Seems like for " Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz"  processor we are missing  these flags

x2apic  -SandyBridge
hle     -Haswell
smep    -Haswell
rtm     -Haswell



This issue should be reproducable on a RHEL6.5 as well given the processor is " Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz" (Server : Dell Talon), I have not verified it on a RHEL though.

Created attachment 860041 [details]
cat /proc/cpuinfo for Intel_Core_i3-4130, processor in which issue is found

Created attachment 860042 [details]
cat /proc/cpuinfo for Intel_Haswell_E3-1270, processor. Has all the flags.

Was able to remove these flags (x2apic,hle,smep,rtm) from cpu_max.xml and verify that rhev-h shows the processor as Haswell...!


I could probably modify the cpu_max.xml to add new entry for this(type ? ) processor, 

but would want Intel`s comment on the list of supported flags for this processor "Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz". 

Need their confirmation to see if these flags are really not supported on Intel_Core_i3-4130 or its something to do with our server alone.. ! 

x2apic  -SandyBridge
hle     -Haswell
smep    -Haswell
rtm     -Haswell

redhat,

can you please include intel folks to comment on this.

Thanks in Advance.

Moving this to libvirt as RHEV-H pulls the CPU informations from there.

I don't see anything wrong here. The cpu_map.xml file describes CPU models and how what features they have in QEMU. When libvirt says host CPU is Westmere (plus some additional features), it basically means that the best CPU available to a guest without emulating or disabling some features is Westmere. And that's exactly the case here. When starting a guest with Haswell CPU model, one would have to disable hle, smep, and rtm features.

BTW, as far as I know, Intel was involved in the definition of the new CPU models.

(In reply to Jiri Denemark from comment #8)
> When libvirt says host CPU is
> Westmere (plus some additional features), it basically means that the best
> CPU available to a guest without emulating or disabling some features is
> Westmere. And that's exactly the case here. When starting a guest with
> Haswell CPU model, one would have to disable hle, smep, and rtm features.


Do you mean to say that some Haswell processor such as "Intel_Haswell_E3-1270" is available to Guest as Haswell processor 
but some Haswell "Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz"  are available as "Westmere" ??

OK, let's be more specific, your CPU is advertised by libvirt as Westmere plus a bunch of additional features which unfortunately does not include some of the features that the Haswell CPU model has. When describing host CPU, libvirt cannot express that the CPU is a model with some features disabled, it can only express additional features. Thus, it choses the best CPU model that the host CPU can fully satisfy and lists additional features on top of it. So you see something like the following in capabilities XML:

  <cpu>
    <arch>x86_64</arch>
    <model>Westmere</model>
    <vendor>Intel</vendor>
    <topology .../>
    <feature name='pclmuldq'/>
    <feature name='tsc-deadline'/>
    <feature name='xsave'/>
    <feature name='avx'/>
    <feature name='rdtscp'/>
    <feature name='fma'/>
    <feature name='pcid'/>
    <feature name='movbe'/>
    <feature name='fsgsbase'/>
    <feature name='bmi1'/>
    <feature name='avx2'/>
    <feature name='bmi2'/>
    <feature name='erms'/>
    <feature name='invpcid'/>
    <!-- some other features that none of the CPU models lists -->
  </cpu>

Guest CPUs compatible with the above host CPU model are, e.g.:

  <cpu match='exact'>
    <model>Westmere</model>
  </cpu>

  <cpu match='exact'>
    <model>SandyBridge</model>
    <feature policy='force' name='x2apic'/>
  </cpu>

  <cpu match='exact'>
    <model>Haswell</model>
    <feature policy='force' name='x2apic'/>
    <feature policy='disable' name='hle'/>
    <feature policy='disable' name='smep'/>
    <feature policy='disable' name='rtm'/>
  </cpu>

In other words, Westmere is the best CPU model that can be used without disabling some features. You can also use SandyBridge but you either have to disable x2apic or force it (which tells libvirt not to check if the host CPU supports such feature). When using Haswell, you need to disable several other features to get a guest CPU that is compatible with your host CPU.

Thanks for clarifying Jiri, I belive we can close this bug now.

Reopening this, as ovirt-ndoe is the incorrectly using the libvirt informations.
As said in comment 10 - libvirt only tells us the highest possible CPU family based on the available CPU flags.
But the information dialog ovirt-node provides should contain the real host CPU informations, independently of what flags are activated or not.

*** Bug 1059021 has been marked as a duplicate of this bug. ***

Maybe we can use /proc/cpuinfo, dmidecode or some other faciliyt to get some informations ..

this seems not Haswell cpu specific issue, it aslo happens on other microarchitectures processors.

Due to technical limitations (the CPU does not include a textual representation of the CPU Family) we can not determine the correct CPU Family on the host side.
The attached patch will only display the CPU Type instead, because this information is provided by the CPU itself.

The patch drops the Family from the information dialog, but shows the correct Type.

This is a mass change, moving bugs of merged patches into MODIFIED.

Please correct the state, if you think that the move was not justified.

verified on rhev-hypervisor6-6.6-20150114.0.el7ev, 
the CPU Family information is dropped, only correct CPU Model name is displayed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-0160.html