Created attachment 287459 [details] /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/x86_64-pc-linux-gnu/libgcc/config.log This is causing qemu-kvm-0.15 to make gcc thing that it is a simple pentium-m vs native (core2 usually (this is a first gen i7)). Notice the colect_gcc_options Configured with: /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-esp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.5.3-r1 p1.0, pie-0.4.5' Thread model: posix gcc version 4.5.3 (Gentoo Hardened 4.5.3-r1 p1.0, pie-0.4.5) COLLECT_GCC_OPTIONS='-B/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/gcc/' '-c' '-g' '-O2' '-pipe' '-v' '-Q' '-fPIE' '-pie' cc1 -v -iprefix /root/../../../lib/gcc/x86_64-pc-linux-gnu/4.5.3/ conftest.c -D_FORTIFY_SOURCE=2 -march=pentium-m -mcx16 -msahf -mpopcnt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic -fno-strict-overflow -dumpbase conftest.c -auxbase conftest -g -O2 -version -fPIE -fstack-protector-all -o - | as -V -Qy --64 -o conftest.o - This is causing my x86_64 vm to be detected as only being 32bit. I attached the file, look at line 99
I can manually set march and emerge gcc successfully. (tested via setting to core2)
I don't think -march=native can work reliably in Qemu, but I'm no expert.
(In reply to comment #2) > I don't think -march=native can work reliably in Qemu, but I'm no expert. It did for 4.4, but that could have been a fluke.
Created attachment 287461 [details] cpuinfo
run the code i posted in Bug 384129 and post the output here
(In reply to comment #5) > run the code i posted in Bug 384129 and post the output here test arch # ./cpuid.o 0x1: 0x623 0x40800 0x80802001 0x178bfbfd 0x80000000: 0x8000000a 0x68747541 0x444d4163 0x69746e65 0x80000001: 0x623 0 0x1 0x2191abfd 0x80000002: 0x554d4551 0x72695620 0x6c617574 0x55504320
(In reply to comment #2) > I don't think -march=native can work reliably in Qemu, but I'm no expert. Qemu/kvm isnt the problem the virtual cpu is. If i just "pass through" my host cpu to the guest there isnt a problem: gcc -### -march=native -E /usr/include/stdlib.h 2>&1 | grep "/usr/libexec/gcc/.*cc1" results in: "/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1" "-E" "-quiet" "/usr/include/stdlib.h" "-D_FORTIFY_SOURCE=2" "-march=core2" "-mcx16" "-msahf" "--param" "l1-cache-size=32" "--param" "l1-cache-line-size=64" "--param" "l2-cache-size=4096" "-mtune=core2" "-fno-strict-overflow" "-fPIE" "-fstack-protector-all" which is correct, now if i try to do the same while using the qemu cpu well all hell breaks lose. So something must have changed in the gcc auto-detection code that makes it trip up, but for all i know it could potentially be qemu problem or gcc
You need to configure the proper CPU to be passed through. If you're using libvirt, then you'll need to edit the appropriate XML settings. If you're using virt-manager on top of libvirt, then you'll have a fancy GUI to edit it. If you've just launched qemu from the command line then you need to pass the proper -cpu command. Try -cpu ? to get more info on the CPU types. If you want your guest to support everything your host does then you need to run it with -cpu host. http://www.linux-kvm.org/page/Tuning_KVM If you're using libvirt/virt-manager and need more help, I'll gladly help you on IRC during the week during normal US business hours.
(In reply to comment #8) > You need to configure the proper CPU to be passed through. If you're using > libvirt, then you'll need to edit the appropriate XML settings. If you're using > virt-manager on top of libvirt, then you'll have a fancy GUI to edit it. If > you've just launched qemu from the command line then you need to pass the > proper -cpu command. Try -cpu ? to get more info on the CPU types. If you want > your guest to support everything your host does then you need to run it with > -cpu host. > > http://www.linux-kvm.org/page/Tuning_KVM > > If you're using libvirt/virt-manager and need more help, I'll gladly help you > on IRC during the week during normal US business hours. Is there a reason that gcc will not support the emulated CPU? The emulated CPU is very useful for live migration.
Created attachment 288999 [details, diff] patch to gcc for longmode detection detects longmode now for core2 :D
(In reply to comment #9) > (In reply to comment #8) > > You need to configure the proper CPU to be passed through. If you're using > > libvirt, then you'll need to edit the appropriate XML settings. If you're using > > virt-manager on top of libvirt, then you'll have a fancy GUI to edit it. If > > you've just launched qemu from the command line then you need to pass the > > proper -cpu command. Try -cpu ? to get more info on the CPU types. If you want > > your guest to support everything your host does then you need to run it with > > -cpu host. > > > > http://www.linux-kvm.org/page/Tuning_KVM > > > > If you're using libvirt/virt-manager and need more help, I'll gladly help you > > on IRC during the week during normal US business hours. > > Is there a reason that gcc will not support the emulated CPU? The emulated CPU > is very useful for live migration. You still have yet to show me what virtual CPU you are using. kvm32, qemu32, kvm64, qemu64? grapico ~ # gcc -E -dM -march=native - < /dev/null | grep core2 #define __core2__ 1 #define __tune_core2__ 1 #define __core2 1 grapico ~ # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 2 model name : QEMU Virtual CPU version 0.15.0 stepping : 3 cpu MHz : 2992.480 cache size : 4096 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no 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 pni cx16 hypervisor lahf_lm bogomips : 5984.96 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: I can not confirm the issue you are experiencing.
(In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #8) > > > You need to configure the proper CPU to be passed through. If you're using > > > libvirt, then you'll need to edit the appropriate XML settings. If you're using > > > virt-manager on top of libvirt, then you'll have a fancy GUI to edit it. If > > > you've just launched qemu from the command line then you need to pass the > > > proper -cpu command. Try -cpu ? to get more info on the CPU types. If you want > > > your guest to support everything your host does then you need to run it with > > > -cpu host. > > > > > > http://www.linux-kvm.org/page/Tuning_KVM > > > > > > If you're using libvirt/virt-manager and need more help, I'll gladly help you > > > on IRC during the week during normal US business hours. > > > > Is there a reason that gcc will not support the emulated CPU? The emulated CPU > > is very useful for live migration. > > You still have yet to show me what virtual CPU you are using. kvm32, qemu32, > kvm64, qemu64? > > grapico ~ # gcc -E -dM -march=native - < /dev/null | grep core2 > #define __core2__ 1 > #define __tune_core2__ 1 > #define __core2 1 > grapico ~ # cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 2 > model name : QEMU Virtual CPU version 0.15.0 > stepping : 3 > cpu MHz : 2992.480 > cache size : 4096 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > 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 pni cx16 hypervisor lahf_lm > bogomips : 5984.96 > clflush size : 64 > cache_alignment : 64 > address sizes : 40 bits physical, 48 bits virtual > power management: > > I can not confirm the issue you are experiencing. I am not defining a cpu, it is whatever is default.
nocona would be better then core2 (due to the flags)
Created attachment 289599 [details, diff] patch to gcc for longmode detection (changed from core2 to nocona)
I've added this to the kvm command line so that the cpu that is passed though is recognized (the original CPU has a never manufactured family/model). -cpu qemu64,family=6,model=15 -cpu host will be default http://article.gmane.org/gmane.comp.emulators.qemu/120697
*** Bug 474954 has been marked as a duplicate of this bug. ***
