Bug 549264

Summary: Export nonstop_tsc to the guest on an host without it
Product: Red Hat Enterprise Linux 5 Reporter: jason wang <jasowang>
Component: kernelAssignee: Prarit Bhargava <prarit>
Status: CLOSED NOTABUG QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: low    
Version: 5.6CC: john.cooper, llim, tburke, virt-maint, ykaul, zamsden
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-20 19:05:15 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    
Attachments:
Description Flags
x86info log on the guest
none
x86info log on the host none

Description jason wang 2009-12-21 04:48:28 UTC
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

Comment 1 john cooper 2010-01-09 07:54:11 UTC
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

Comment 2 john cooper 2010-01-11 20:33:48 UTC
Can I get a pointer to the host/guest install images used to create
the above test scenario?

Comment 3 jason wang 2010-01-12 07:08:11 UTC
Created attachment 383185 [details]
x86info log on the guest

Comment 4 jason wang 2010-01-12 07:08:49 UTC
Created attachment 383187 [details]
x86info log on the host

Comment 5 jason wang 2010-01-12 07:10:26 UTC
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.

Comment 6 jason wang 2010-01-12 07:24:32 UTC
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.

Comment 7 john cooper 2010-01-12 15:33:30 UTC
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?

Comment 8 jason wang 2010-01-12 15:55:05 UTC
Hello john:
   You could use root as the user and 654321 as the password to log into 10.66.85.201.

Comment 9 john cooper 2010-01-21 15:12:15 UTC
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.

Comment 16 Zachary Amsden 2011-01-20 19:04:20 UTC
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.