Bug 518062

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

There is active discussion upstream wrt this bug

http://www.redhat.com/archives/libvir-list/2009-September/msg00157.html

Need QA ack please!

libvirt-0.7.6-0.pre20100121.el6 has been built in RHEL-6-candidate
and includes the feature,

Daniel

Steps to Reproduce:
1.Make sure that CPU topology is consistent between /proc/cpuinfo file and virsh capabilities:

The following cpu information is consistent with corresponding cpu item of topology from virsh capabilities.

Core info comes from /proc/cpuinfo
Socket info comes from /sys/devices/system/cpu/cpu#/topology/physical_package_id 
Thread info comes from /sys/devices/system/cpu/cpu#/topology/thread_siblings

# virsh capabilities
<capabilities>

  <host>
    <uuid>44454c4c-5100-1050-8058-b1c04f4b3258</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>core2duo</model>
      <topology sockets='1' cores='2' threads='1'/>
      <feature name='lahf_lm'/>
      <feature name='sse4.1'/>
      <feature name='xtpr'/>
      <feature name='cx16'/>
      <feature name='tm2'/>
      <feature name='est'/>
      <feature name='vmx'/>
      <feature name='ds_cpl'/>
      <feature name='pbe'/>
      <feature name='tm'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='acpi'/>
      <feature name='ds'/>
    </cpu>
  ......
</capabilities>

And also running virsh nodeinfo to assist verification: 

# virsh nodeinfo
CPU model:           x86_64
CPU(s):              2
CPU frequency:       2992 MHz
CPU socket(s):       1
Core(s) per socket:  2
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         7994872 kB

2. Find at the named cpu model in /usr/share/libvirt/cpu_map.xml and make sure that the features for the CPU model + the extra features listed in the capabilities, match the features in /proc/cpuinfo:

The following features haven't been covered on my machine(x86_64):
Don't cover total number: 14
the constant_tsc isn't covered
the arch_perfmon isn't covered
the pebs isn't covered
the bts isn't covered
the rep_good isn't covered
the aperfmperf isn't covered
the dtes64 isn't covered
the smx isn't covered
the pdcm isn't covered
the sse4_1 isn't covered
the xsave isn't covered
the tpr_shadow isn't covered
the vnmi isn't covered
the flexpriority: isn't covered

Please running shell script in the attachment about details.

Version-Release number of selected component (if applicable):
# cat /etc/redhat-release 
Red Hat Enterprise Linux release 6.0 Beta (Santiago)
# uname -a
Linux dhcp-66-70-62.nay.redhat.com 2.6.32-33.el6.x86_64 #1 SMP Thu Jun 3 13:00:03 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
# rpm -q libvirt
libvirt-0.8.1-10.el6.x86_64
# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.80.el6.x86_64

Additional info: 
# cat /proc/cpuinfo|grep flags|uniq
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority

Created attachment 427350 [details]
cpu flags shell script

The set of CPU features libvirt recognizes and advertises in host capabilities is not a complete list of features linux kernel is aware of. Thus, you can see features in /proc/cpuinfo which are not present in the xml. And sometimes, libvirt may use a different name for the same feature (currently it is sse4.1 vs sse4_1) so the second test is not right. It's probably better to test whether all features advertised by libvirt are present in /proc/cpuinfo, i.e., that libvirt doesn't invent some features.

(In reply to comment #9)
> The set of CPU features libvirt recognizes and advertises in host capabilities
> is not a complete list of features linux kernel is aware of. Thus, you can see
> features in /proc/cpuinfo which are not present in the xml. And sometimes,
> libvirt may use a different name for the same feature (currently it is sse4.1
> vs sse4_1) so the second test is not right. It's probably better to test
> whether all features advertised by libvirt are present in /proc/cpuinfo, i.e.,
> that libvirt doesn't invent some features.    


You mean I need to test whether all features from cpu_mal.xml are present in /proc/cpuinfo, these features includes model features + standard features + extended features in the cpu_map.xml, the libvirt will invent many features if this is right, if not, which feature should be included by testing? model features? or others?

Only the bits listed in the 'flags:' line cpuinfo should appear in the XML. eg

flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority

I meant that all features from capabilities (both those mentioned explicitly and those defined by CPU model) should appear in /proc/cpuinfo. On the other hand, /proc/cpuinfo may contain additional features which are not shown by virsh capabilities, which is fine.

(In reply to comment #11)
> Only the bits listed in the 'flags:' line cpuinfo should appear in the XML. eg
> 
> flags  : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36
> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc
> arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est
> tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority    

Hi Daniel,
I think that the second testing is correct in Comment 7 based on your above suggestion, we need to test whether flags value from /proc/cpuinfo appear in cpu_map.xml, in
fact, except sse4_1 is named as sse4.1 in cpu_map.xml, the following 13 features haven't been covered by cpu_map.xml on my x86_64 machine:
1.constant_tsc 
2.arch_perfmon 
3.pebs 
4.bts 
5.rep_good 
6.aperfmperf 
7.dtes64 
8.smx 
9.pdcm 
10.xsave 
11.tpr_shadow 
12.vnmi 
13.flexpriority

But, Jiri gave my another suggestion for the second testing, I think the suggestion should be about the first testing, right?

In addition, WRT the first testing, feature 'ds' from virsh capabilities doesn't appears in /proc/cpuinfo, in other words, flags from /proc/cpuinfo don't include 'ds' on my x86_64 machine, Is it right?

The cpu_map.xml file does not contain all existing features, it merely contains features which qemu understands. Thus it's expected that some features from /proc/cpuinfo are not covered in the xml.

'ds' is just another example of different names, it's called 'dts' in /proc/cpuinfo. These differences are annoying but we needed to use the names which qemu uses.

The bug has been fixed on RHEL6-beta with libvirt-0.8.1-12.el6.x86_64.


For the bug, we only need to check whether topology and feature from capabilities appear in /proc/cpuinfo based on Jiri's suggestion, so the first testing is enough in Comment 7, and the following topology and feature appear in /proc/cupinfo:
<topology sockets='1' cores='2' threads='1'/>
<feature name='lahf_lm'/>
<feature name='sse4.1'/>
<feature name='xtpr'/>
<feature name='cx16'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>

Note, 'sse4.1' and 'ds' are renamed based on qemu require in capabilities.


# uname -a
Linux dhcp-66-70-62.nay.redhat.com 2.6.32-37.el6.x86_64 #1 SMP Sun Jun 20 19:29:35 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
# rpm -q libvirt
libvirt-0.8.1-12.el6.x86_64
# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.90.el6.x86_64

Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.