Bug 670104

Summary:	guest cpu frequency don't change while host cpu frequency change
Product:	Red Hat Enterprise Linux 6	Reporter:	Suqin Huang <shuang>
Component:	qemu-kvm	Assignee:	Zachary Amsden <zamsden>
Status:	CLOSED WONTFIX	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.1	CC:	mkenneth, tburke, virt-maint
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-03-22 22:19:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	580953

Description Suqin Huang 2011-01-17 08:20:33 UTC

Description of problem:
set host scaling_governor as "ondemand" while guest is booting, and set to powersave after guest start, guest cpu frequency don't change while host cpu frequency change.

Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.129.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. set host scaling_governor as "ondemand"
modprobe cpufreq_powersave
modprobe cpufreq_ondemand
echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

2. boot guest
/usr/libexec/qemu-kvm -drive file=/home/shuang/images/RHEL-Server-5.6-virtio.qcow2,index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,format=qcow2,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,id=virtio-disk1 -device virtio-net-pci,mac=9a:36:59:d1:03:04,netdev=idM1j2ed,id=ndev00idM1j2ed,bus=pci.0,addr=0x3 -netdev tap,id=idM1j2ed,ifname=t0-144735-LFT4,script=/usr/Auto/autotest/client/tests/kvm/scripts/qemu-ifup,downscript=no -m 4096 -smp 2,cores=1,threads=1,sockets=2 -cpu Opteron_G2,+sse2 -vnc :10 -rtc base=utc,clock=host,driftfix=none -M rhel6.0.0 -usbdevice tablet -no-kvm-pit-reinjection -enable-kvm -monitor stdio

3. bind guest to cpu
taskset -pc 1,pid

4. check host cpufre during guest booting
[root@dhcp-91-146 cpufreq]# cat cpuinfo_cur_freq 
2400000

5. Change host scaling_governor to powersave
echo powersave > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
[root@dhcp-91-146 cpufreq]# cat scaling_governor
powersave

6. Check host cpufre 
[root@dhcp-91-146 cpufreq]# cat cpuinfo_cur_freq 
1000000

7. Check guest cpufre
#cat /proc/cpuinfo

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 6
model name	: AMD Opteron 22xx (Gen 2 Class Opteron)
stepping	: 1
cpu MHz		: 2411.308
cache size	: 512 KB
fpu		: yes

  
Actual results:
guest cpufrq don't change while host cpufrq change

Expected results:


Additional info:
1. host
cpu:
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
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy

2. kernel:
2.6.32-94.el6.x86_64

Comment 2 Zachary Amsden 2011-03-22 22:19:32 UTC

We don't want to change this behavior; when the host TSC changes in a way that is visible to the guest, that's a bug, not a desired behavior.

We can't emulate hardware and vendor specific notification methods that will work in all kernels on all hardware.  In some situations, there is no way to report this event to the guest.

So instead, we should be keeping the guest TSC rate constant, by scaling the TSC catching up the TSC when it is behind, or emulating it if is is racing ahead.