[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] Migrating decrementer

From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] Migrating decrementer
Date: Thu, 25 Feb 2016 04:33:58 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

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->tb_env->tb_offset = 0;

    cpu->tb_env->tb_offset =
        qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) * tb_env->tb_freq +
            cpu->tb_env->tb_offset -

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]