qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] Migrating decrementer (was: Re: [PATCH 4/4]


From: David Gibson
Subject: Re: [Qemu-devel] [Qemu-ppc] Migrating decrementer (was: Re: [PATCH 4/4] target-ppc: ensure we include the decrementer value during migration)
Date: Tue, 26 Jan 2016 16:51:20 +1100
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Jan 25, 2016 at 06:20:21PM +0100, BALATON Zoltan wrote:
> On Mon, 25 Jan 2016, David Gibson wrote:
> >Remember, we only ever compute the guest timebase value at the moment
> >the guest requests it - actually maintaining a current timebase value
> >makes sense in hardware, but would be nuts in software.
> >
> >The timebase is a function of real, wall-clock time, and the migration
> >destination has a notion of wall-clock time without reference to the
> >source.
> >
> >So what you need to transmit for migration is enough information to
> >compute the guest timebase from real-time - essentially just an offset
> >between real-time and the timebase.
> 
> I don't know anything about all this but if I understand your conversation
> correctly then you don't really need an offset between real-time and
> timebase. That would be true assuming the source and destination has the
> same real-time but that's not necessarily true.

No, it's not necessarily true, but if it's not that's not really our
problem to deal with.

We do ensure that the guest timebase doesn't go backwards in this
situation, but if the source and destination hosts don't have
synchronized time, the guest real time may jump.  But since we have no
idea whether the source or destination had a better notion of
real-time, we can't really do any better.

> What would be needed is an
> offset between source timebase and destination's real time. That is, besides
> the offset on the source you would also need to work out the difference in
> the "real-time" on the source and destination and correct the transferred
> offset with this after migration.

Yeah, that's not really possible in the current migration model.  Nor
is it something that's really qemu's job.

> Is this handled somehow in QEMU (for example by doing some message exchange
> to establish the clock difference between the source and destination during
> migration) or is it assumed that migration always needs synchronised clocks
> done by some external means?

Migration itself doesn't need synced clocks, but if the hosts'
real-time isn't well behaved, you can't really expect the guest's real
time to be well behaved.

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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