On Tue, Feb 07, 2017 at 06:02:13PM +0800, Wanpeng Li wrote: > 2016-11-08 3:41 GMT+08:00 Marcelo Tosatti <mtosatti@xxxxxxxxxx>: > > On Mon, Nov 07, 2016 at 03:46:11PM +0000, Dr. David Alan Gilbert wrote: > >> * Marcelo Tosatti (mtosatti@xxxxxxxxxx) wrote: > >> > This patch, relative to pre-copy migration codepath, > >> > measures the time between vm_stop() and pre_save(), > >> > which includes copying the remaining RAM to destination, > >> > and advances the clock by that amount. > >> > > >> > In a VM with 5 seconds downtime, this reduces the guest > >> > clock difference on destination from 5s to 0.2s. > >> > > >> > Tested with Linux and Windows 2012 R2 guests with -cpu XXX,+hv-time. > >> > >> One thing that bothers me is that it's only this clock that's > >> getting corrected; doesn't it cause things to get upset when > >> one clock moves and the others dont? > > > > If you are correlating the clocks, then yes. > > > > Older Linux guests get upset (marking the TSC clocksource unstable > > because the watchdog checks TSC vs kvmclock), but there is a workaround for it > > in newer guests > > (kvmclock interface to notify watchdog to not complain). > > Could you point out which interface? I didn't find it. > > Regards, > Wanpeng Li PVCLOCK_GUEST_STOPPED flag. > > > > > Note marking TSC clocksource unstable on older guests is harmless > > because kvmclock is the standard clocksource. > > > > For Windows guests, i don't know that Windows correlates between different > > clocks. > > > > That is, there is relative control as to which software reads kvmclock > > or Windows TIMER MSR, so i don't see the need to advance every clock > > exposed. > > > >> Shouldn't the pause delay be recorded somewhere architecturally > >> independent and then be a thing that kvm-clock happens to use and > >> other clocks might as well? > > > > In theory, yes. In practice, i don't see the need for this... > > > > -- > > 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
