On Sun, 2022-03-20 at 14:39 +0100, Paolo Bonzini wrote:
> 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.
Hm, I still don't really understand why it's a 5-tuple and why we care
about the *host* TSC at all.
Fundamentally, guest state is *guest* state. There is a 3-tuple of
{ NTP-synchronized time of day, Guest KVM clock, Guest TSC value }
(plus a TSC offset from vCPU0, for each other vCPU perhaps.)
All else is redundant, and including host values is just wrong.
We can already do clock-advancing live migration by adding the
appropriate number of nanoseconds, and the appropriate number of TSC
ticks, to the values being restored on the destination host based on
the time at which the migrated instance is being restored there, as
compared with the originally stored time-of-day.
I understand why KVM would want to use the *same* host TSC value for
calculating the time-of-day as well as the guest KVM clock and the
guest TSC value — so that all three elements of that 3-tuple reflect
precisely the same moment in time.
I don't understand why the actual *value* of the host TSC is something
that userspace needs to see.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
