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