On 3/15/23 20:57, Sean Christopherson wrote:
In the case of live migration, using the KVM_VCPU_TSC_OFFSET approach to
preserve the TSC value and apply a known offset would require
duplicating the TSC scaling computations in userspace to account for
frequency differences between source and destination TSCs.
Hence, if userspace wants to set the TSC to some known value without
having to deal with TSC scaling, and while also being resilient against
scheduling delays, neither KVM_SET_MSRS nor KVM_VCPU_TSC_VALUE are
suitable options.
Requiring userspace to handle certain aspects of TSC scaling doesn't seem
particularly onerous, at least not relative to all the other time insanity. In
other words, why should KVM take on more complexity and a mostly-redundant uAPI?
Yeah, it seems like the problem is that KVM_GET_CLOCK return host
unscaled TSC units (which was done because the guest TSC frequency is at
least in theory per-CPU, and KVM_GET_CLOCK is a vm ioctl)?
Perhaps it's more important (uAPI-wise) for KVM to return the precise
guest/host TSC ratio via a vcpu device attribute?
Paolo
