Bug 620562
| Summary: | CentOS 5.5 x86_64 host Fedora12,13 x86_64 guests Qemu cpu detected as a 32-bit processor when -march=native is passed to gcc | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | william metcalf <william.metcalf> |
| Component: | kvm | Assignee: | john cooper <john.cooper> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.7 | CC: | bcao, crobinso, gcosta, jakub, M8R-7fin56, mkenneth, nobody, tburke, virt-maint |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-03-17 18:31:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 580948 | ||
|
Description
william metcalf
2010-08-02 20:59:09 UTC
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 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 |