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
--
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
