On 24/02/16 12:31, Juan Quintela wrote:
>> I don't really understand the question. Migration has no equivalent
>> in real hardware, so there's no "real" behaviour to mimic. If we
>> freeze the TB during migration, then the guest's clock will get out of
>> sync with wall clock time, and in a production environment that's
>> really bad. So no, we absolutely must not freeze the TB during
>> migration.
>>
>> When the guest has been explicitly paused, there's a case to be made
>> either way.
>
> If this is the case, can't we just change the device to just read the
> clock from the host at device insntantiation and call it a day?
>
> (* Notice that I haven't seen the previous discussion *)
>
> On migration, having a post-load function that just loads the right
> value for that device should work. Or if we want to make it work for
> pause/cont, we should have a notifier to be run each time "cont" is
> issued, and put a callback there?
>
> Or I am missing something improtant?
Right, that's roughly the approach I was thinking when I wrote my last
reply - for KVM derive the timebase from the virtual clock similar to
TCG and adjust on CPU start, e.g.
cpu_reset():
cpu->tb_env->tb_offset = 0;
cpu_start/resume():
cpu->tb_env->tb_offset =
qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) * tb_env->tb_freq +
cpu->tb_env->tb_offset -
qemu_clock_get_ns(QEMU_CLOCK_HOST)
Is there any reason why this shouldn't work? My understanding is that
guests supporting KVM_REG_PPC_TB_OFFSET should compensate correctly for
the timebase if tb_offset is the difference from the host timebase at
guest virtual time zero.
ATB,
Mark.
