From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: TSC deadline timer in guests vs. migration? Date: Tue, 5 Jul 2016 23:41:49 +0200 Message-ID: <72214cff-7446-a0a3-a321-6fb9d67fac0f@redhat.com> 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> <20160705203905.GA21766@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Eduardo Habkost , David Matlack , Peter Hornyack , KVM list To: Marcelo Tosatti Return-path: Received: from mail-wm0-f46.google.com ([74.125.82.46]:37053 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755516AbcGEVlx (ORCPT ); Tue, 5 Jul 2016 17:41:53 -0400 Received: by mail-wm0-f46.google.com with SMTP id a66so169650593wme.0 for ; Tue, 05 Jul 2016 14:41:52 -0700 (PDT) In-Reply-To: <20160705203905.GA21766@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 05/07/2016 22:39, Marcelo Tosatti wrote: > 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. Right, QEMU 2.6 does that. But even worse, instead of tsc_always_catchup you get a WARN if the user requests a TSC rate below hardware spped. >> I'd like to make KVM_SET_TSC_KHZ fail if TSC scaling is not supported by >> the processor. > > Thats a good idea. Good! Paolo