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:
address@hidden /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 1126809000
address@hidden /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 17308857
address@hidden /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 103710852
address@hidden /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 15292604
address@hidden /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 96695295
address@hidden /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 1126761234
address@hidden /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 1126762522
address@hidden /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.
address@hidden /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.