qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [QEMU PATCH v2] kvmclock: advance clock by time window


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [QEMU PATCH v2] kvmclock: advance clock by time window between vm_stop and pre_save
Date: Mon, 7 Nov 2016 20:03:50 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

* Marcelo Tosatti (address@hidden) wrote:
> On Mon, Nov 07, 2016 at 03:46:11PM +0000, Dr. David Alan Gilbert wrote:
> > * Marcelo Tosatti (address@hidden) 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).
> 
> 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... 

It seems unlikely to me that x86 is the only one that will want
to do something similar.

Dave

--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]