> Am 03.02.2016 um 06:59 schrieb David Gibson <da...@gibson.dropbear.id.au>: > >> 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