On 3/19/22 14:13, David Woodhouse wrote:
On 3/19/22 12:54, Paolo Bonzini wrote:
On 3/19/22 09:08, David Woodhouse wrote:
If a basic API requires this much documentation, my instinct is to
*fix* it with fire first, then document what's left.
I agree, but you're missing all the improvements that went in together
with the offset API in order to enable the ugly algorithm.
A userspace-friendly API for migration would be more like KVM on the
source host giving me { TIME_OF_DAY, TSC } and then all I have to do on
the destination host (after providing the TSC frequency) is give it
precisely the same data.
I guess you meant {hostTimeOfDay, hostTSC} _plus_ the constant
{guestTSCScale, guestTSCOffset, guestTimeOfDayOffset}. That would work,
and in that case it wouldn't even be KVM returning that host information.
I would have said nobody cares about the host TSC value and frequency.
That is for KVM to know and deal with internally.
There are two schools as to how to do migration. The QEMU school is to
just load back the guest TOD and TSC and let NTP resync. They had
better be synced, but a difference of a few microseconds might not matter.
This has the advantage of not showing the guest that there was a pause.
QEMU is doing it this way due to not having postcopy live migration
for a long time; precopy is subject to longer brownout between source
and destination, which might result in soft lockups. Apart from this it
really has only disadvantage.
The Google school has the destination come up with the guest TOD and TSC
that takes into account the length of the brownout phase. This is where
the algorithm in Documentation/ comes into play, and why you need the
host pair as well. Actually Google does not use it because they already
have precise time available to userspace as part of Spanner. Maybe so
does Amazon (?), but for the rest of the world the host {TOD, TSC} pair
is required to compute what the guest TSC "should look like" on the
destination.
Paolo
For guest migration it should be as simple as "guest TSC frequency is <F>,
and the TSC value was <X> at (wallclock time <T>|KVM_CLOCK time <T>).
Not sure I have an opinion on whether the objective time reference is the
timeofday clock or the KVM clock.
