[libvirt-users] Fwd: Haswell 4770 misidentified as Sandy Bridge

[Martin Kletzander]

On 06/19/2013 05:32 AM, Michael Giardino wrote:
> Sorry to blow up everyone's email on this but I tried something new and
> found a different problem. I uninstalled all the debian package (libvirt,
> kvm, qemu, virt-manager, etc.) and then remade all the packages and
> installed them. Haswell again shows up in virt-manager, but now any CPU I
> choose including kvm64 and qemu64 give the same error:
> 
> root at mal:~# virsh create /etc/libvirt/qemu/debian7-nonsmp.xml
> 2013-06-19 03:09:42.836+0000: 24248: info : libvirt version: 1.0.6
> 2013-06-19 03:09:42.836+0000: 24248: warning :
> virLogParseDefaultPriority:1581 : Ignoring invalid log level setting
> error: Failed to create domain from /etc/libvirt/qemu/debian7-nonsmp.xml
> error: internal error Cannot find suitable CPU model for given data
> 

I guess you probably wanted to show that old, "working", domain cannot
be defined, but I can't leave following not mentioned.  If the machine
is defined in /etc/libvirt already, it is loaded upon libvirtd startup,
you shouldn't use those files directly, but instead of that use 'virsh
start <domain>'

> This is using the old "working" xml configuration. I then let virt-manager
> create a new one by installing a new VM using the qcow2 image from before.
> If I use the new one created by virt-manager I get the same error. The only
> major difference I see in the two xmls is
> 
> <os>
>     <type arch='x86_64' machine='pc-i440fx-1.5'>hvm</type>
>     <boot dev='hd'/>
> </os>
> 

This has nothing to do with the CPU model, the reason this is different
is that by default the newest machine type is selected to incorporate
newest qemu features & settings which we simply cannot explain to end user.

> in the new one compared to the old one below.
> 
> I'm starting to think I've hosed the whole thing and need to delete
> everything, remove with configuration files, and start over.
> 

I'll check that flags for you, but in the meantime, is there a
possibility that /etc/libvirt/cpu_map.xml is somehow screwed up in
Debian packaging?

[...]
>>  eax in    eax      ebx      ecx      edx
>> 00000000 0000000d 756e6547 6c65746e 49656e69
>> 00000001 000306c3 01100800 7ffafbff bfebfbff
>> 00000002 76036301 00f0b5ff 00000000 00c10000
>> 00000003 00000000 00000000 00000000 00000000
>> 00000004 00000000 00000000 00000000 00000000
>> 00000005 00000040 00000040 00000003 00042120
>> 00000006 00000077 00000002 00000009 00000000
>> 00000007 00000000 00000000 00000000 00000000

>From the looks of it, I'd guess both libvirt and cpuid are misdetecting
Intel instructions like invpcid etc.  The cpuid program doesn't clean
ecx, but we do clear e[bcd]x registers before calling cpuid.

I'm looking into kernel flag detection to see how they do it (since it
is visible in /proc/cpuinfo), because I can't see any other reason why
this should fail.

Could you create a bug for this issue in the meantime?

Thanks,
Martin