Re: [libvirt-users] Fwd: Haswell 4770 misidentified as Sandy Bridge
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@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