Please don't send vN+1 In-Reply-To vN, the threading messes up lore and other tooling, and becomes really problematic for humans when N gets large. 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?
