On 26/01/16 22:31, Mark Cave-Ayland wrote: > For a typical savevm/loadvm pair I see something like this: > > savevm: > > tb->guest_timebase = 26281306490558 > qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) = 7040725511 > > loadvm: > > cpu_get_host_ticks() = 26289847005259 > tb_off_adj = -8540514701 > qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) = 7040725511 > cpu_ppc_get_tb() = -15785159386 > > But as cpu_ppc_get_tb() uses QEMU_CLOCK_VIRTUAL for vmclk we end up with > a negative number for the timebase since the virtual clock is dwarfed by > the number of TSC ticks calculated for tb_off_adj. This will work on a > PPC host though since cpu_host_get_ticks() is also derived from the > timebase.
Ah... the magic of signed numbers. Here's another attempt but this time with cpu_ppc_get_tb() printed unsigned: savevm: tb->guest_timebase = 2597350923332 qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) = 4199081744 cpu_ppc_get_tb() = 69704756 loadvm: cpu_get_host_ticks() = 2606380782824 tb_off_adj = -9029859492 qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) = 4199081744 cpu_ppc_get_tb() = 18446744064749396880 This implies that the cpu_ppc_get_tb() value post-migration is far too low - presumably because tb_env->tb_freq is only 16MHz compared to the actual TSC rate? ATB, Mark.
