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