On 06/08/20 00:01, Jim Mattson wrote:
>>> but perhaps I'm missing something obvious.
>> Not necessarily obvious, but I can think of a rather contrived example
>> where the sync heuristics break down. If we're running nested and get
>> migrated in the middle of a VMM setting up TSCs, it's possible that
>> enough time will pass that we believe subsequent writes to not be of
>> the same TSC generation.
>
> An example that has been biting us frequently in self-tests: migrate a
> VM with less than a second accumulated in its TSC. At the destination,
> the TSCs are zeroed.
Yeah, good point about selftests. But this would be about the sync
heuristics messing up, and I don't understand how these ioctls improve
things.
>> My immediate reaction was that we should just migrate the heuristics
>> state somehow
>
> Yeah, I completely agree. I believe this series fixes the
> userspace-facing issues and your suggestion would address the
> guest-facing issues.
I still don't understand how these ioctls are any better for userspace
than migrating MSR_IA32_TSC. The host TSC is different between source
and destination, so the TSC offset will be different.
I am all for improving migration of TSC state, but I think we should do
it right, so we should migrate a host clock / TSC pair: then the
destination host can use TSC frequency and host clock to compute the new
TSC value. In fact, such a pair is exactly the data that the syncing
heuristics track for each "generation" of syncing.
To migrate the synchronization state, instead, we only need to migrate
the "already_matched" (vcpu->arch.this_tsc_generation ==
kvm->arch.cur_tsc_generation) state.
Putting all of this together, it would be something like this:
- a VM-wide KVM_CLOCK/KVM_SET_CLOCK needs to migrate
vcpu->arch.cur_tsc_{nsec,write} in addition to the current kvmclock
value (it's unrelated, but I don't think it's worth creating a new
ioctl). A new flag is set if these fields are set in the struct. If
the flag is set, KVM_SET_CLOCK copies the fields back, bumps the
generation and clears kvm->arch.nr_vcpus_matched_tsc.
- a VCPU-wide KVM_GET_TSC_INFO returns a host clock / guest TSC pair
plus the "already matched" state. KVM_SET_TSC_INFO will only use the
host clock / TSC pair if "already matched" is false, to compute the
destination-side TSC offset but not otherwise doing anything with it; or
if "already matched" is true, it will ignore the pair, compute the TSC
offset from the data in kvm->arch, and update
kvm->arch.nr_vcpus_matched_tsc.
Paolo
