On 26/02/16 04:35, David Gibson wrote: >> Sign. And let me try that again, this time after caffeine: >> >> cpu_start/resume(): >> cpu->tb_env->tb_offset = >> muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL), >> cpu->tb_env->tb_freq, NANOSECONDS_PER_SECOND) + >> cpu->tb_env->tb_offset - >> cpu_get_host_ticks(); >> >> This should translate to: at CPU start, calculate the difference between >> the current guest virtual timebase and the host timebase, storing the >> difference in cpu->tb_env->tb_offset. > > Ummm... I think that's right. Except that you need to make sure you > calculate the tb_offset just once, and set the same value to all guest > CPUs. Otherwise the guest TBs may be slightly out of sync with each > other, which is bad (the host should have already ensure that all host > TBs are in sync with each other).
Nods. The reason I really like this solution is because it correctly handles both paused/live machines and simplifies the migration logic significantly. In fact, with this solution the only information you would need in vmstate_ppc_timebase for migration would be the current tb_offset so the receiving host can calculate the guest timebase from the virtual clock accordingly. > We really should make helper routines that each Power machine type can > use for this. Unfortunately we can't put it directly into the common > ppc cpu migration code because of the requirement to keep the TBs > synced across the machine. Effectively I believe there are 2 cases here: TCG and KVM. For TCG all of this is a no-op since tb/decr are already derived from the virtual clock + tb_offset already so that really just leaves KVM. >From what you're saying we would need 2 hooks for KVM here: one on machine start/resume which updates tb_offset for all vCPUs and one for vCPU resume which updates just that one particular vCPU. Just curious as to your comment regarding helper routines for each Power machine type - is there any reason not to enable this globally for all Power machine types? If tb_offset isn't supported by the guest then the problem with not being able to handle a jump in timebase post-migration still remains exactly the same. The other question of course relates to the reason this thread was started which is will this approach still support migrating the decrementer? My feeling is that this would still work in that we would encode the number of ticks before the decrementer reaches its interrupt value into vmstate_ppc_timebase, whether high or low. For TCG it is easy to ensure that the decrementer will still fire in n ticks time post-migration (which solves my particular use case), but I don't have a feeling as to whether this is possible, or indeed desirable for KVM. ATB, Mark.