On Fri, 2023-03-24 at 12:22 +0100, Paolo Bonzini wrote: > 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? Perhaps. Although that really does suck as a userspace experience. See the patch I just sent.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
