On 08.01.2010, at 19:22, Blue Swirl wrote: > On Fri, Jan 8, 2010 at 6:07 PM, Alexander Graf <ag...@suse.de> wrote: >> >> On 08.01.2010, at 19:04, Blue Swirl wrote: >> >>> On Fri, Jan 8, 2010 at 5:43 PM, Alexander Graf <ag...@suse.de> wrote: >>>> Our guest systems need to know by how much the timebase increases every >>>> second, >>>> so there usually is a "timebase-frequency" property in the cpu leaf of the >>>> device tree. >>>> >>>> This property is missing in OpenBIOS, as is the "clock-frequency" property >>>> that >>>> tells the guest how fast the CPU is. FWIW that one is only used for >>>> /proc/cpuinfo though. >>>> >>>> With qemu, Linux's fallback timebase speed and qemu's internal timebase >>>> speed >>>> match up. With KVM, that is no longer true. The guest is running at the >>>> same >>>> timebase speed as the host. >>>> >>>> This leads to massive timing problems. On my test machine, a "sleep 2" >>>> takes >>>> about 14 seconds with KVM enabled. >>>> >>>> This patch exports the timebase and clock frequencies to OpenBIOS, so it >>>> can >>>> then put them into the device tree. I'll push the OpenBIOS change with the >>>> NewWorld patch set, once that's either been reviewed or applied. >>> >>> IIRC copying the host CPU frequency to guest was rejected earlier for x86. >> >> Well IIRC x86 Linux tries to find out the cpu frequency itself. >> PPC Linux doesn't - it completely relies on entries in the device tree. > > The frequency could be a parameter for the -cpu flag, like -cpu > 970fx,frequency=1000000000.
We could implement that as an override to the current static code path. For KVM it doesn't make any sense, as you really want to see the host frequency in the guest here. That's what users expect. Period. Alex
