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 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. tsc_always_catchup is high on the list of things that I hate in KVM. I'd like to make KVM_SET_TSC_KHZ fail if TSC scaling is not supported by the processor. 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
