qemu-devel
[Top][All Lists]
Advanced

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

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


From: Alexander Graf
Subject: Re: [Qemu-devel] [RFC PATCH] spapr: support time base offset migration
Date: Mon, 9 Sep 2013 08:06:53 +0200


Am 09.09.2013 um 07:58 schrieb Alexey Kardashevskiy <address@hidden>:

> On 09/09/2013 03:50 PM, Alexander Graf wrote:
>> 
>> 
>> Am 09.09.2013 um 04:40 schrieb Alexey Kardashevskiy <address@hidden>:
>> 
>>> 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 :).

> 
> 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 :).

Alex

> 
> 
> -- 
> Alexey



reply via email to

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