[Users] ovirt reporting wrong cpu family (2nd server)

[Martin Kletzander]

On 03/02/2013 08:46 PM, Itamar Heim wrote:
> On 02/03/2013 18:39, Adrian Gibanel wrote:
>> I've read again the wiki page and as you might ask for it here's the
>> cpuinfo flags output:
>>
>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
>> pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
>> pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
>> xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
>> ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2
>> x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb
>> xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
>>
>> If we check the mentioned cpu_max.xml file we find :
>>
>>      <model name='SandyBridge'>
>>        <model name='Westmere'/>
>>        <feature name='pclmuldq'/>
>>        <feature name='x2apic'/>
>>        <feature name='tsc-deadline'/>
>>        <feature name='xsave'/>
>>        <feature name='avx'/>
>>        <feature name='rdtscp'/>
>>      </model>
>>
>> So I suppose that pclmuldq is expected in the flags but it's not
>> there. Isn't it?
> 
> well, it kind of looks like a bug, since you have pclmulqdq (additional
> 'q' in the middle').
> martin?
> 

Hi, this is expected.  While working on these features, the names
sometime change and in this case pclmulqdq is the same as pclmuldq.
Mostly it is referred to it as pclmulqdq, but when this feature was
added in qemu, the name was without the 'q', alias was added later on:

http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02376.html

>> # virsh -r capabilities
>> 
>> <capabilities>
>> 
>>   <host>
>>     <uuid>00000000-0000-0000-0000-002590a41888</uuid>
>>     <cpu>
>>       <arch>x86_64</arch>
>>       <model>SandyBridge</model>

But from this output (which I pasted from the older mail, so the
indentation may not fit), I see libvirt is detecting the CPU perfectly
in this case.

>>
>> So I need to add my specific model at hand and trying to infer which
>> are the specific flags for it?
>> Or maybe that needs something more to be hacked in the libvirt code...
>> and thus I should wait for libvirt people to add it? Well, I mean,
>> going to their ML and asking there?
>>
>> Or isn't there any hope for my particular sandbridge cpu?
>>

There definitely is, as mentioned above.  There almost always is, I
remember only one CPU without a chance and that was because the HW
itself really didn't know the function.  Unfortunately, sometimes
(HW-dependant) it really has to be set in BIOS/UEFI.  For some changes
there are utilities, so you don't have to have physical access to the
machine, but as seen from the capabilities, this is not your case.

>> Thank you.
>>
>> ----- Mensaje original -----
>>
>>> De: "Adrian Gibanel" <adrian.gibanel at btactic.com>
>>> Para: users at ovirt.org
>>> CC: "Itamar Heim" <iheim at redhat.com>, "Jithin Raju"
>>> <rajujith at gmail.com>,
>>> "Martin Kletzander" <mkletzan at redhat.com>
>>> Enviados: Sábado, 2 de Marzo 2013 17:21:43
>>> Asunto: Re: [Users] ovirt reporting wrong cpu family (2nd server)
>>
>>> This is another server which I have also problems with. I cannot select
>>> SandyBridge as the cpu type.
>>> Still oVirt 3.1 in Fedora 17.
>>
>>> * Tecnology : Sandy Bridge E
>>> * CPU : Intel Xeon E5-1620
>>> * Cores / Threads : 4 / 8
>>> * Frecuency : 3.6GHz / 3.8GHz Turbo Boost
>>
>>> #cpuinfo:
>>> Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
>>
>>> # rpm -qa | grep -E 'vdsm|libvirt' | sort
>>> libvirt-0.9.11.9-1.fc17.x86_64
>>> libvirt-client-0.9.11.9-1.fc17.x86_64
>>> libvirt-daemon-0.9.11.9-1.fc17.x86_64
>>> libvirt-daemon-config-network-0.9.11.9-1.fc17.x86_64
>>> libvirt-daemon-config-nwfilter-0.9.11.9-1.fc17.x86_64
>>> libvirt-lock-sanlock-0.9.11.9-1.fc17.x86_64
>>> libvirt-python-0.9.11.9-1.fc17.x86_64
>>> vdsm-4.10.0-10.fc17.x86_64
>>> vdsm-cli-4.10.0-10.fc17.noarch
>>> vdsm-python-4.10.0-10.fc17.x86_64
>>> vdsm-xmlrpc-4.10.0-10.fc17.noarch
>>
>>> # virsh -r capabilities
>>
>>> <capabilities>
>>> [...]
>>
>>> ----- Mensaje original -----
>>
>>>> At first, let me say that this is very weird CPU detection as according
>>>> to these flags, the processor described in here should be "Nehalem".
>>>> Could you try running 'virsh -r capabilities' on the host to check what
>>>> libvirt reports?
>>
>>> -- 
>