On 01/10/21 21:11, Marcelo Tosatti wrote:
That said, the point is: why not advance the_TSC_ values
(instead of kvmclock nanoseconds), as doing so would reduce
the "the CLOCK_REALTIME delay which is introduced during migration"
for both kvmclock users and modern tsc clocksource users.
It already does, that's the cool part. Take again the formula here:
guest_off_1 = t_0 + guest_off_0 + (k_1 - k_0) * freq - t_1
and set:
t_1 = t_0 + host_off_0_1 + (k_1 - k_0) * freq
i.e. t_0 and t_1 are different because 1) the machines were booted at
different times, which is host_off_0_1 2) t_1 includes the migration
downtime between k_0 and k_1
Now you have:
guest_off_1 = t_0 + guest_off_0 + (k_1 - k_0) * freq
- t_0 - real_off_n - (k_1 - k_0) * freq
guest_off_1 = guest_off_0 - host_off_0_1
That is, the TSC is exactly the same as it was on the source, just
adjusted because the two machines were booted at different times.
The need to have precise (ns, cycle) pairings is exactly because it
ensures that everything cancels in the formula, and all that is left is
the differences in the TSC of the two hosts.
Paolo
So yes, i also like this patchset, but would like it even more
if it fixed the case above as well (and not sure whether adding
the migration delta to KVMCLOCK makes it harder to fix TSC case
later).
