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.

Reply via email to