On Wed, 2023-03-15 at 12:57 -0700, Sean Christopherson wrote: > > On Thu, Feb 02, 2023, Simon Veith 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? Because it offers userspace a simple and easy to use API. You get the time information, you put the time information. Now, if you want to *document* the actual calculations that userspace would be forced to do just to preserve the existing relationship between the guest TSC and the time of day / host TSC (for LM / LU respectively).... well, you can try, but it exceeded my "if it needs documenting this much, fix it first" threshold. Does userspace even *have* what it needs to do this *right*?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
