On Tue, Oct 18, 2016 at 03:41:03PM +0200, Paolo Bonzini wrote: > > > On 18/10/2016 01:58, Marcelo Tosatti wrote: > > > We should also blacklist the TSC deadline timer when invtsc is not > > > available. > > > > Actually, a nicer fix would be to check the different > > frequencies and scale the deadline relative to the difference. > > You cannot know what exactly the guest was thinking when it set the TSC > deadline. Perhaps it wanted an interrupt when the TSC was exactly > 9876543210. You can't expect the correlation between TSC value and timer interrupt execution to be precise, because of the delay between HW timer expiration and interrupt execution. So you have to live with the fact that the TSC deadline timer can be late (which is the same thing as with your paravirt solution, in case of migration to host with faster TSC freq) (which to me renders the argument above invalid). Solution for old guests and new guests: Just save how far ahead in the future the TSC deadline timer is supposed to expire on the source (in ns), in the destination save all registers (but disable TSC deadline timer injection), arm a timer in QEMU for expiration time, reenable TSC deadline timer reinjection. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
