Description of problem: I work on the suricata project and as part of our QA process we have a CentOS-5.5 x86_64 server running Qemu/KVM as a host and Fedora 11,12,13 x86_64 and i686 guests that we use to perform automated build/regression testing. Part of our code utilizes lockless ring buffers via compare and swap macros when available in gcc. We default to compiling our engine with the -march=native gcc option as some older versions of debain/slackware etc build for i386 targets and thus these macro's are not enabled unless we pass this option. I realize this bit isn't your problem just a bit of background ;-). With gcc 4.4.4-10 on a Fedora 12,13 x86_64 guest it appears as if the Qemu Virtual cpu is detected as a pentium-m(32-bit proc) when -march=native is passed as an option to gcc. It seeems because of this, gcc is no longer capable of producing 64-bit binaries on my Fedora 12/13 x86_64 guests. Fedora 12/13 gcc 4.4.4-10 gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' -march=pentium-m --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=generic cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : QEMU Virtual CPU version 0.9.1 stepping : 3 cpu MHz : 2261.066 cache size : 32 KB fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm up rep_good pni hypervisor bogomips : 4522.13 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: If I monkey with my configure.in script to get around the 64-bit libs I end up with the following when trying to compile. "CPU you selected does not support x86-64 instruction set" Just as an example in Ubuntu-LTS-10.04 the Qemu Virtual cpu is detected as a core2 chip. gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' -D_FORTIFY_SOURCE=2 -march=core2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=core2 -fstack-protector CentOS 5.5 x86_64 host rpm -qa | grep -P "(qemu|kvm)" kvm-83-164.el5_5.12 qemu-0.9.0-4 kmod-kvm-83-164.el5_5.12 Version-Release number of selected component (if applicable): gcc-4.4.10 Fedora 12/13 x86_64 kvm guest os's kvm-83-164.el5_5.12,qemu-0.9.0-4 CentOS 5.5 x86_64 host How reproducible: everytime ;-) Steps to Reproduce: 1. download suricata on a x86_64 Fedora12/13 Qemu/KVM guest http://www.openinfosecfoundation.org/download/suricata-1.0.0.tar.gz 2. Follow install doc to install pre-reqs etc. http://www.openinfosecfoundation.org/doc/INSTALL.txt 3. run ./configure it will blow up on the 64-bit libs. 4. re-run configure and pass the --disable-gccmarch-native option. The IDS engine will compile just fine. Actual results: using -march=native on a Fedora 12/13 x86_64 guest and Qemu/KVM host sets the march to be a 32-bit processor Expected results: using -march=native on a Fedora 12/13 x86_64 guest and Qemu/KVM host should set march to be a 64-bit processor. Additional info:
The virtual CPU doesn't claim to support ssse3, therefore it can't be handled like Core2, so Ubuntu gcc is buggy. Either don't use -march=native when compiling in this guest, or reassign to KVM to get SSSE3 support there (and CX16 e.g. too).
Ok I will re-assign but I guess the bigger issue is that march=native assigns the cpu type to be a 32-bit only processor on a 64-bit platform. I don't claim to be a gcc expert at all, but is there anything in the cpu flags, etc that can be used to determine that the Qemu virtual cpu is 64-bit capable? I guess for documentation here is the output from other 64-bit guests I'm running. CentOS-5.5 gcc 4.4.0 gcc44 -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' -march=core2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=core2 Fedora 11 gcc 4.4.1-2 gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' -march=core2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=core2 Ubuntu 9.04 gcc 4.3.3 gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' -D_FORTIFY_SOURCE=2 -march=core2 --param l1-cache-size=32 --param l1-cache-line-size=64 -mtune=core2 Ubuntu 8.04 gcc 4.2.4 gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' -march=nocona -mtune=generic Ubuntu 9.10 gcc 4.4.1 -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' -D_FORTIFY_SOURCE=2 -march=core2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=core2 -fstack-protector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
Reopening against kvm...
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
Reproduced on INTEL host guest info: 2.6.33.3-85.fc13.x86_64 host info: # uname -r 2.6.18-237.el5 # rpm -q kvm kvm-83-224.el5 # cat /proc/cpuinfo processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9500 @ 2.83GHz stepping : 10 cpu MHz : 2000.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : 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 syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips : 5652.47 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: steps: 1.download suricata 2.#./configure configure: WARNING: pcre.h: present but cannot be compiled configure: WARNING: pcre.h: check for missing prerequisite headers? configure: WARNING: pcre.h: see the Autoconf documentation configure: WARNING: pcre.h: section "Present But Cannot Be Compiled" configure: WARNING: pcre.h: proceeding with the compiler's result checking for pcre.h... no configure: error: pcre.h not found ... 3.#./configure --disable-gccmarch-native compile successfully. Additional info: Can not reproduced on AMD host
(In reply to comment #1) > The virtual CPU doesn't claim to support ssse3, therefore it can't be handled > like Core2, so Ubuntu gcc is buggy. > Either don't use -march=native when compiling in this guest, or reassign to KVM > to get SSSE3 support there (and CX16 e.g. too). How are you launching the guest when gcc is assuming a 32-bit target cpu? Reason being is rhel5 qemu does support ssse3 and cx16 flags: # grep -r ssse3 . ./target-i386/helper.c: "tm2", "ssse3", "cid", NULL, NULL, "cx16", "xtpr", NULL, .. however these cpu flags must be requested either explicitly on the qemu command line or implied in a cpu model (or -cpu host). Assuming they are the cause of gcc mis-configuring its target code generation.
(In reply to comment #9) I use Virtual Machine Manager to create and manage the VM's. Regards, Will > (In reply to comment #1) > > The virtual CPU doesn't claim to support ssse3, therefore it can't be handled > > like Core2, so Ubuntu gcc is buggy. > > Either don't use -march=native when compiling in this guest, or reassign to KVM > > to get SSSE3 support there (and CX16 e.g. too). > > How are you launching the guest when gcc is assuming a 32-bit > target cpu? Reason being is rhel5 qemu does support ssse3 and > cx16 flags: > > # grep -r ssse3 . > ./target-i386/helper.c: "tm2", "ssse3", "cid", NULL, NULL, "cx16", > "xtpr", NULL, > > .. however these cpu flags must be requested either explicitly on the > qemu command line or implied in a cpu model (or -cpu host). Assuming > they are the cause of gcc mis-configuring its target code generation.
Could one of the reporters provide the qemu command line they are using? If using virt-manager or libvirt, this is in /var/log/libvirt/qemu/$vmname.log
It doesn't really seem like a KVM bug at all. Not virt manager as well. As John had mentioned already, we keep the defaults sane, which means not all cpus will get all the flags of your host. There are ways to edit the xml file and force a specific cpu to be used, which will allow you all flags you need, and the ones gcc seem to be expecting. I will close this bug temporarily as NOTABUG, which seems the most adequate state from my perspective. If using a handcrafted libvirt xml to force a cpu model doesn't solve your problem, then you have a real bug, and please don't hesitate to reopen. Thanks
I spoke to Cole on the above and while virt-manager doesn't yet allow the user to request individual feature flags analogous to qemu, it will expose such if contained in the selected libvirt cpu model. So choice of appropriate model via virt-manager should circumvent this problem. virt-manager support for explicit user selection of individual feature flags is currently a TBD. If for some reason this is justified in this particular case the, bug here should become a feature request.
I Know this is closed but it is the top result on google for this issue. If you do not have access to change the flags passed to your VM these cflags work. -march=nocona -mno-ssse3 -mno-sse3