Re: [Qemu-devel] [RFC PATCH] spapr: support time base offset migration

[Alexander Graf <agraf@suse.de>]

On 13.09.2013, at 00:20, David Gibson wrote:

> On Mon, Sep 09, 2013 at 08:06:53AM +0200, Alexander Graf wrote:
>> 
>> 
>> Am 09.09.2013 um 07:58 schrieb Alexey Kardashevskiy <aik@ozlabs.ru>:
>> 
>>> On 09/09/2013 03:50 PM, Alexander Graf wrote:
>>>> 
>>>> 
>>>> Am 09.09.2013 um 04:40 schrieb Alexey Kardashevskiy <aik@ozlabs.ru>:
>>>> 
>>>>> On 09/06/2013 01:11 AM, Alexander Graf wrote:
>>>>>> 
>>>>>> On 05.09.2013, at 16:26, Benjamin Herrenschmidt wrote:
>>>>>> 
>>>>>>> On Thu, 2013-09-05 at 16:14 +0200, Andreas Färber wrote:
>>>>>>> 
>>>>>>>> Are you thinking of POWER8 having a different frequency than POWER8 in
>>>>>>>> compat mode? Because migration from one -cpu to another is not supported
>>>>>>>> elsewhere.
>>>>>>>> 
>>>>>>>> Even if we want to migrate from one POWER7 revision to another, we
>>>>>>>> should let the destination use the revision of the source (guest ABI!),
>>>>>>>> via property if need be. Anything else will lead to confusion as to what
>>>>>>>> is supported and what is not. That -cpu host is the default for
>>>>>>>> convenience shouldn't relieve admins/libvirt to think about sensible
>>>>>>>> setups like they have to on x86.
>>>>>>> 
>>>>>>> Besides POWER8 uses 512Mhz too :-) It's been architected so it's
>>>>>>> unlikely to change from now on.
>>>>>> 
>>>>>> Ok, ditch the tb frequency then. We can always default to 512Mhz when it's absent.
>>>>> 
>>>>> 
>>>>> QEMU uses what kvmppc_get_tbfreq() returns. And ppc_tb_t carries this
>>>>> value. It does not use 512MHz automatically but migration should always
>>>>> assume 512MHz :-/
>>>>> 
>>>>> If we remove it, I would like to add assert(tb_freq!=512MHz) into
>>>>> timebase_pre_save() and timebase_post_load(), is that ok?
>>>> 
>>>> Good point. This would break TCG migration, right?
>>> 
>>> 
>>> In TCG we do not need any timebase offset at all, the time should migrate
>>> as is, no? :)
>> 
>> I hope so, but we need to make sure we don't assert() in that case :).
> 
> Hrm.. that doesn't sound right.  Whether you have KVM or TCG, what you
> need in the migration stream is enough data points that you can deduce
> the guest timebase from the host real time.  On KVM that translates
> into a diff between guest and host timebase, but on TCG you'll need to
> implement that differently

I'd claim that for TCG we don't care about accuracy of the time base across live migration, so I'd be happy to simply ignore the adjustments we'd do with KVM there. Otherwise things would get heavily complicated.

> 
>>> 
>>> It could break something like power5 migration under PR KVM, do not know...
>> 
>> Well, today we don't support full migration with PR KVM yet - IIRC we don't have access to all state. But that may change in the future.
>> 
>> I think it's ok to restrict live migration to machines with the same
>> tb frequency when kvm is enabled. Whether you implement it through a
>> hardcoded 512Mhz or through a timebase value that gets live migrated
>> and then compared is up to you - both ways work for me :).
> 
> I don't think it's possible to allow KVM migration between hosts of
> different tb frequency.  But I think encoding the frequency in the
> stream and verifying it is a better option.  It might be useful for
> migration on 970, and it might be useful for TCG migration and it
> might be useful for TCG<->KVM migration. (For a TCG migration
> destination you *can* potentially set the tb frequency according to
> what you're told).

Yup, IIUC that's what Alexey's gut feeling told him too (and I concur) and is what he's doing ;).


Alex