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

[David Gibson]

On Mon, Sep 09, 2013 at 08:06:53AM +0200, Alexander Graf wrote:
> 
> 
> 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 :).

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

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

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

pgpGEzsNXplgl.pgp
Description: PGP signature