Description of problem: During the test, I find that the kvm running on Dual-Core AMD Opteron may export the nonstop_tsc to the guest, but the host in fact lack the support for neither nonstop_tsc nor constant_tsc. Version-Release number of selected component (if applicable): Guest kernel: 2.6.18-164.8.1.el5 Host kernel: 2.6.18-176.el5 KVM version: kmod-kvm-83-137.el5 kvm-tools-83-137.el5 etherboot-zroms-kvm-5.4.4-12.el5 kvm-qemu-img-83-137.el5 kvm-debuginfo-83-137.el5 kvm-83-137.el5 How reproducible: 100% Steps to Reproduce: 1. boot the vm 2. use cat /proc/cpuinfo the see the flags in guest 3. use cat /proc/cpuinfo in the host to see flags Actual results: 1. nonstop_tsc is existed in the guest but not in the host Expected results: 1. nonstop_tsc should not in the guest without the support of the host Additional info: 1. qemu-kvm command: /usr/local/staf/test/RHEV/kvm-new/kvm-test/tests/kvm/qemu -name vm1 -monitor tcp:0:6001,server,nowait -drive file=/usr/local/staf/test/RHEV/kvm-new/kvm-test/tests/kvm/images/RHEL-Server-5.4-32.raw,if=ide,cache=writethrough,boot=on -net nic,vlan=0,model=e1000,macaddr=00:19:27:57:E8:00 -net tap,vlan=0,ifname=e1000_0_6001,script=/usr/local/staf/test/RHEV/kvm-new/kvm-test/tests/kvm/scripts/qemu-ifup-switch,downscript=no -m 4096 -smp 2 -usbdevice tablet -rtc-td-hack -no-hpet -cpu qemu64,+sse2 -no-kvm-pit-reinjection -vnc :0 2. Could see nonstop_tsc in the guest of 32bit and PAE version, could not see nonstop_tsc in the x86_64 version. 3. cpuinfo in the host: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : Dual-Core AMD Opteron(tm) Processor 1216 stepping : 3 cpu MHz : 1000.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips : 2009.36 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : Dual-Core AMD Opteron(tm) Processor 1216 stepping : 3 cpu MHz : 1000.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips : 2009.36 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 4. cpuinfo in the guest: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : QEMU Virtual CPU version 0.9.1 stepping : 3 cpu MHz : 2411.573 cache size : 512 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 sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm up nonstop_tsc pni ^^^^^^^^^^^ bogomips : 4823.14
Unsure whether this is an issue of qemu passing bad data or the guest kernel incorrectly interpreting the flag. Could you run: # x86info -a -f on both host and guest and attach a log of the output? If needed you can find a binary of the utility here: http://people.redhat.com/~jcooper/cpuid/utils/x86info/x86info-1.24/x86info
Can I get a pointer to the host/guest install images used to create the above test scenario?
Created attachment 383185 [details] x86info log on the guest
Created attachment 383187 [details] x86info log on the host
Hello john: I've used the x86info at http://www.codemonkey.org.uk/projects/x86info/ because the link your show me does not work under 32bit guest. And during the execution in guest, the following warning could be found: /dev/cpu/0/msr: No such file or directory The log have been attached.
Hello john: I've reproduced this problem in root@654321:10.66.85.201, and the 32bit RHEL image could be found at /tmp/kvm_autotest_root/images.
This may be a false positive. The TscInvariant flag is defined as fn 0x8000_0007: edx & 0x00000100 which isn't set on host nor guest as reported by x86info: $ grep -r 80000007 /tmp/x86info.* /tmp/x86info.guest:eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 /tmp/x86info.host:eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 0000007f /tmp/x86info.host:eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 0000007f Don't know why the guest kernel is reporting it in /proc/cpuinfo. Can you send me login info to 10.66.85.201?
Hello john: You could use root as the user and 654321 as the password to log into 10.66.85.201.
Appears to be a possible quirk in the guest kernel as direct cpuid access via x86info shows TscInvariant not to be set (as above). Not dismissing the case outright until further investigation but moving to 5.6 as a non-blocker per Dor's request.
This bug is deeply confused; the hypervisor doesn't export nonstop_tsc field, this is determined by the guest. Additionally, the original poster was tweaking the CPU type with qemu, which caused the nonstop_tsc flag to be turned on when it shouldn't have been. However, note that under kvm, nonstop_tsc should be true since the TSC virtualization should never stop. It's actually really minor, as nonstop_tsc isn't actually used for anything other than a flag to userspace. I think it's safe to close.