Re: [Qemu-ppc] [Qemu-devel] Migrating decrementer

[Alexander Graf]

> Am 03.02.2016 um 06:59 schrieb David Gibson <address@hidden>:
> 
>> On Tue, Feb 02, 2016 at 11:41:40PM +0000, Mark Cave-Ayland wrote:
>> On 01/02/16 00:52, David Gibson wrote:
>> 
>>>> Thanks for more pointers - I think I'm slowly getting there. My current
>>>> thoughts are that the basic migration algorithm is doing the right thing
>>>> in that it works out the number of host ticks different between source
>>>> and destination.
>>> 
>>> Sorry, I've take a while to reply to this.  I realised the tb
>>> migration didn't work the way I thought it did, so I've had to get my
>>> head around what's actually going on.
>> 
>> No problem - it's turning out to be a lot more complicated than I
>> initially expected.
>> 
>>> I had thought that it transferred only meta-information telling the
>>> destination how to calculate the timebase, without actually working
>>> out the timebase value at any particular moment.
>>> 
>>> In fact, what it sends is basically the tuple of (timebase, realtime)
>>> at the point of sending the migration stream.  The destination then
>>> uses that to work out how to compute the timebase from realtime there.
>>> 
>>> I'm not convinced this is a great approach, but it should basically
>>> work.  However, as you've seen there are also some Just Plain Bugs in
>>> the logic for this.
>>> 
>>>> I have a slight query with this section of code though:
>>>> 
>>>>    migration_duration_tb = muldiv64(migration_duration_ns, freq,
>>>>                                     NANOSECONDS_PER_SECOND);
>>>> 
>>>> This is not technically correct on TCG x86 since the timebase is the x86
>>>> TSC which is running somewhere in the GHz range, compared to freq which
>>>> is hard-coded to 16MHz.
>>> 
>>> Um.. what?  AFAICT that line doesn't have any reference to the TSC
>>> speed.  Just ns and the (guest) tb).  Also 16MHz is only for the
>>> oldworld Macs - modern ppc cpus have the TB frequency architected as
>>> 512MHz.
>> 
>> On TCG the software timebase for the Mac guests is fixed at 16MHz so how
>> does KVM handle this?
> 
>> Does it compensate by emulating the 16MHz timebase
>> for the guest even though the host has a 512HMz timebase?
> 
> No, it can't.  The timebase is not privileged, so there's no way to
> virtualize it for the guest.  So, the best we can do is to detect KVM,
> override the guest device tree with the host timebase frequency and
> hope the guest reads it rather than assuming a fixed value for the
> platform.

IIRC Mac OS (9&X) calculates the tb frequency using the cuda clock as 
reference. So it doesn't honor our dt properties like Linux, but it can adapt 
to different frequencies.


Alex