On 3/21/22 13:16, David Woodhouse wrote:
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. [...]
I don't understand why the actual *value* of the host TSC is something
that userspace needs to see.
Ok, I understand now.
You're right, you don't need the value of the host TSC; you only need a
{hostTOD, guestNS, guestTSC} tuple for every vCPU recorded on the source.
If all the frequencies are the same, that can be "packed" as {hostTOD,
guestNS, anyTSC} plus N offsets. The N offsets in turn can be
KVM_VCPU_TSC_OFFSET if you use the hostTSC, or the offsets between vCPU0
and the others if you use the vCPU0 guestTSC.
I think reasoning in terms of the host TSC is nicer in general, because
it doesn't make vCPU0 special. But apart from the aesthetics of having
a "special" vCPU, making vCPU0 special is actually harder, because the
TSC frequencies need not be the same for all vCPUs. I think that is a
mistake in the KVM API, but it was done long before I was involved (and
long before I actually understood this stuff).
Paolo
