Re: TSC deadline timer in guests vs. migration?

[Marcelo Tosatti <mtosatti@redhat.com>]

On Mon, Jul 04, 2016 at 04:45:06PM -0300, Eduardo Habkost wrote:
> On Mon, Jul 04, 2016 at 04:30:08PM -0300, Marcelo Tosatti wrote:
> > On Mon, Jul 04, 2016 at 01:01:42PM +0200, Paolo Bonzini wrote:
> > > Can bad things happen if a guest using the TSC deadline timer is
> > > migrated?  The guest doesn't re-calibrate the TSC after migration, and
> > > the TSC frequency can and will change unless your data center is
> > > perfectly homogeneous.
> > 
> > It can fire earlier if the destination runs at a higher frequency.
> > It will fire past the configured time if the destination runs at a slower frequency.
> > 
> > Suppose the first case is worse.
> > 
> > Should convert the expiration time to nanoseconds i suppose, and then 
> > convert back on the destination.
> 
> This won't make any difference if the guest sets up a new timer
> after migration (but using the old TSC frequency), will it?

It does, because the timer setup traps to the host, where you can
convert it to the proper value:

                guest_tsc = kvm_x86_ops->read_l1_tsc(vcpu,
native_read_tsc());
                if (likely(tscdeadline > guest_tsc)) {
                        ns = (tscdeadline - guest_tsc) * 1000000ULL;
                        do_div(ns, this_tsc_khz);
                        expire = ktime_add_ns(now, ns);
                        expire = ktime_sub_ns(expire,
lapic_timer_advance_ns);
                        hrtimer_start(&apic->lapic_timer.timer,
                                      expire, HRTIMER_MODE_ABS);
                } else

I've opened a BZ: feel free to take it, or make a reference to it
if you submit a patch to fix it (including the CC'ed Google guys).

https://bugzilla.redhat.com/show_bug.cgi?id=1352909