Bug 620562 - 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
CentOS 5.5 x86_64 host Fedora12,13 x86_64 guests Qemu cpu detected as a 32-bi...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm (Show other bugs)
5.7
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: john cooper
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: Rhel5KvmTier2
  Show dependency treegraph
 
Reported: 2010-08-02 16:59 EDT by william metcalf
Modified: 2014-07-24 23:46 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-17 14:31:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description william metcalf 2010-08-02 16:59:09 EDT
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:
Comment 1 Jakub Jelinek 2010-08-11 03:03:32 EDT
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).
Comment 2 william metcalf 2010-08-11 13:15:38 EDT
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
Comment 3 Jakub Jelinek 2010-08-11 15:45:52 EDT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
Comment 4 Jakub Jelinek 2010-08-11 15:46:30 EDT
Reopening against kvm...
Comment 6 RHEL Product and Program Management 2011-01-11 15:37:15 EST
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.
Comment 7 RHEL Product and Program Management 2011-01-11 17:52:49 EST
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.
Comment 8 Mike Cao 2011-01-30 02:47:35 EST
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
Comment 9 john cooper 2011-03-10 22:57:55 EST
(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.
Comment 10 william metcalf 2011-03-11 10:09:56 EST
(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.
Comment 13 Cole Robinson 2011-03-17 14:30:03 EDT
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
Comment 14 Glauber Costa 2011-03-17 14:31:44 EDT
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
Comment 15 john cooper 2011-03-18 10:10:33 EDT
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.
Comment 16 Anonymous account 2013-08-19 18:03:26 EDT
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

Note You need to log in before you can comment on or make changes to this bug.