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. 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.
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?
Regards,
BALATON Zoltan
