Hide Forgot
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
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.