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.
Again I agree but it would have to be {hostTimeOfDay, hostTSC,
hostTSCFrequency, guestTimeOfDay}.
For migration between hosts, the offset-based API doesn't seem to be
much of an improvement over what we had before.
The improvement is that KVM now provides a consistent {hostTimeOfDay,
hostTSC, guestTimeOfDay} triple, so the "get" part is already okay. I
agree that the "set" leaves a substantial amount of work to the guest,
because *using* that information is left to userspace rather than being
done in KVM. But at least it is correct.
So we only lack a way to retrieve hostTSCFrequency to have an ugly but
fully correct source-side API. Then we can add a new destination-side
ioctl (possibly an extension of KVM_SET_CLOCK?) that takes a
{sourceTimeOfDay, sourceTSC, sourceTSCFrequency, guestTimeOfDay} tuple
and relieves userspace from having to do the math.
Paolo
