From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: TSC deadline timer in guests vs. migration? Date: Tue, 5 Jul 2016 17:39:06 -0300 Message-ID: <20160705203905.GA21766@amt.cnet> References: <759376f0-e0bf-e53a-99e4-598bf14547e3@redhat.com> <20160704193005.GA28201@amt.cnet> <20160704194506.GE4131@thinpad.lan.raisama.net> <20160705125140.GA17664@amt.cnet> <20160705130422.GO4131@thinpad.lan.raisama.net> <03d8c68c-1e86-62bf-f3f2-400a6ef74c25@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eduardo Habkost , David Matlack , Peter Hornyack , KVM list To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38341 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751880AbcGEUjf (ORCPT ); Tue, 5 Jul 2016 16:39:35 -0400 Content-Disposition: inline In-Reply-To: <03d8c68c-1e86-62bf-f3f2-400a6ef74c25@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Jul 05, 2016 at 03:34:20PM +0200, Paolo Bonzini wrote: > > > On 05/07/2016 15:04, Eduardo Habkost wrote: > > On Tue, Jul 05, 2016 at 09:51:41AM -0300, Marcelo Tosatti wrote: > >> 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: > > > > To convert it to the proper value, you need to know what's the > > TSC frequency the guest is assuming. How would you do that? > > In theory with KVM_SET_TSC_KHZ, but it has to be specified manually and Just read the TSC value where the guest has booted and migrate that. > I'm not sure anyone has tested this recently. I'm also not sure how > robust it is, but I'm sure it's fairly slow because it triggers a > kvmclock update on every vmentry. But agreed on that the rest of TSC scaling is poorly thought through. > tsc_always_catchup is high on the list of things that I hate in KVM. It can be dropped probably. I don't see a need for it (tsc scaling was never supported properly because of kvmclock). > I'd like to make KVM_SET_TSC_KHZ fail if TSC scaling is not supported by > the processor. > > Paolo Thats a good idea.