Tuesday, May 16, 2006 8:48 PM Lonnie Mendez wrote: > Kazu wrote: > >>If you set /proc/sys/dev/rtc/max-user-freq to 1024 and disable cpuspeed >>service that is related to SpeedStep/PowerNow! on a host OS, the clock in >>guest OS works fine. >> >>I checked it on i686/x86_64 Linux host. >> > Mind saying how you checked this? I'm on a pentium-III mobile > processor and the only way I've seen so far to make qemu + rdtsc behave > 100% is by disabling ACPI (boot with -noacpi). If I add a simple printf > to cpu_calibrate_ticks it doesn't seem fixed to me: > > [EMAIL PROTECTED] /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi > -kernel-kqemu -soundhw es1370 > ticks_per_sec set as 1126809000 > [EMAIL PROTECTED] /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi > -kernel-kqemu -soundhw es1370 > ticks_per_sec set as 17308857 > [EMAIL PROTECTED] /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi > -kernel-kqemu -soundhw es1370 > ticks_per_sec set as 103710852 > [EMAIL PROTECTED] /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi > -kernel-kqemu -soundhw es1370 > ticks_per_sec set as 15292604 > [EMAIL PROTECTED] /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi > -kernel-kqemu -soundhw es1370 > ticks_per_sec set as 96695295 > [EMAIL PROTECTED] /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi > -kernel-kqemu -soundhw es1370 > ticks_per_sec set as 1126761234 > [EMAIL PROTECTED] /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi > -kernel-kqemu -soundhw es1370 > ticks_per_sec set as 1126762522 > [EMAIL PROTECTED] /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi > -kernel-kqemu -soundhw es1370 > ticks_per_sec set as 49791263 > > The first entry is with the patch attached called > 'ticks_from_proc.patch' applied (I've been using this for almost a > year). It sets the value ticks_per_sec, which happens to be used by a > lot of qemu's hardware emulation, using information in /proc/cpuinfo. > This doesn't fix the time issue as rdtsc is still used every time a > SIGALRM signal occurs for timing, but at least the guest's emulated > hardware runs to speed. > > [EMAIL PROTECTED] /prog/qemu-cvs/qemu-acpi/qemu $ find . -type f -exec fgrep > -l 'ticks_per_sec' {} \; > ./audio/audio.c > ./audio/noaudio.c > ./audio/wavaudio.c > ./monitor.c > ./vl.c > ./vl.h > ./hw/acpi.c > ./hw/adlib.c > ./hw/arm_timer.c > ./hw/cuda.c > ./hw/fdc.c > ./hw/i8254.c > ./hw/i8259.c > ./hw/ide.c > ./hw/mc146818rtc.c > ./hw/mips_r4k.c > ./hw/ppc.c > ./hw/sb16.c > ./hw/sh7750.c > ./hw/slavio_timer.c > ./hw/usb-uhci.c > > The second patch adds the printf statement so you can see this for > yourself. >
Here is values of ticks_per_sec on Athlon 64 3000+ . i686 host: 1790803394 1790784284 1790774719 1790798849 1790814225 x86_64 host: 1790764763 1790815837 1790816089 1790803590 1790771017 If I changed usleep(50 * 1000) to ulseep(500 * 1000) in vl.c, it improves. When cpuspeed service is working in x86_64 host, it becomes: 994896127 994896984 994895713 994897215 994896447 It is because CPU is changed from 1.8GHz to 1GHz. TSC is changed dynamically while QEMU is working. I think your results are from mobile Pentium III. I don't know much but a power management of mobile Pentium III works without software? I attached a patch that I modifed from your patch. It can be applied by patch -p0. I checked it works for Athlon 64 with cpuspeed service (Power Now!). ticks_per_sec changed dynamically but a clock of win2k guest on x86_64 Linux host works fine. If your guest OS is Linux, it is necessary to set clock=pit at guest OS'es startup. TSC may change. I hope it works for SpeedStep. I can't test i686 Linux host because ACPI and cpuspeed doesn't work on my PC. I think it is better to detect CPU change signal and calibrate ticks_per_sec. Regards, Kazu
qemu-20060517-tps_from_proc.patch
Description: Binary data
_______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel