On 3/20/22 09:52, Oliver Upton wrote:
What do you folks think about having a new R/O vCPU attribute that
returns a { TOD, guest_tsc } pair? I believe that would immediately
satisfy the needs of upstream to implement clock-advancing live
migration.
I don't think this adds much. The missing link is on the destination
side, not the source side.
To recap, the data that needs to be migrated from source to destination
is the hostTSC+hostTOD pairing (returned by KVM_GET_CLOCK) plus one of
each of the following:
* either guestTSCOffset or a guestTSC synced with the hostTSC
* either guestTODOffset or a guestTOD synced with the hostTOD.
* either guestTSCScale or hostTSCFreq
Right now we have guestTSCOffset as a vCPU attribute, we have guestTOD
returned by KVM_GET_CLOCK, and we plan to have hostTSCFreq in sysfs.
It's a bit mix-and-match, but it's already a 5-tuple that the
destination can use. What's missing is a ioctl on the destination side
that relieves userspace from having to do the math.
Adding a nicer API just means choosing a different 5-tuple that the
source side sends over to the destination, but it isn't particularly
useful if userspace still has to do the math.
Paolo
