[Qemu-devel] Re: [PATCH] PPC: tell the guest about the time base frequency

[Alexander Graf]

On 08.01.2010, at 19:29, Blue Swirl wrote:

> On Fri, Jan 8, 2010 at 6:27 PM, Alexander Graf <address@hidden> wrote:
>> 
>> On 08.01.2010, at 19:22, Blue Swirl wrote:
>> 
>>> On Fri, Jan 8, 2010 at 6:07 PM, Alexander Graf <address@hidden> wrote:
>>>> 
>>>> On 08.01.2010, at 19:04, Blue Swirl wrote:
>>>> 
>>>>> On Fri, Jan 8, 2010 at 5:43 PM, Alexander Graf <address@hidden> 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.
> 
> Even with 10 guests? What about migration?

Boot up a hypervisor of your choice on any random x86 box. Yes, that's exactly 
what you get.

cpuinfo wrt migration is broken. Since the timebase isn't trapable on ppc, you 
can also expect things to blow up completely when migrating a ppc VM.

That being said the only chance of ever getting migration to work properly on 
ppc would be to notify the guest that the timer frequency just changed, at 
which point it would have to reload it, rebase all timers off the new frequency 
and try to temper over everything as much as it can.

Either way, that's completely orthogonal to the question of exposing the host 
cpu frequency to the guest.

I think we should do what users expect. I agree that having a -cpu flag to set 
the exposed frequency is a good idea. However, the default shouldn't be 
hardcoded but determined as cleverly as possible.

If you like to do the -cpu flag, you're more than welcome to do so. I'm trying 
to fix bugs for now, getting ppc64 working fine in qemu. And there are 
seriously worse things out there than a lacking way of defining the cpu 
frequency with -cpu I'd rather spend my time on.

Alex