[Xen-devel] Re: [PATCH] [Bugfix][pv-ops] Guest get stucked after migration

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Tue, 2011-03-22 at 04:19 +0000, Frank Pan wrote:
> On Tue, Mar 22, 2011 at 2:26 AM, Frank Pan <frankpzh@xxxxxxxxx> wrote:
> > In recent pv-ops kernel, pvclock is not guaranteed as monotone.
> > After a migration, pvclock can produce smaller cycle count.
> >
> > [The test is performed on next-2.6.32 tree]
> > The issue occured when uptime(sender) > uptime(target), and with
> > CONFIG_GENERIC_TIME. The guest get stucked after the migration,
> > doing a huge loop inside update_wall_time, until the overflow of
> > 64-bit unsigned offset.
> >
> > The following patch fixed this issue by introducing a global sign.
> > Xen pvclock will update the cycle_last with the newest cycle count
> > on the first read after migration.
> 
> It seems the issue is not that simple. This issue can be well solved by
> the suspend/resume code of timekeeper sysdev. However, the recent
> code may think this is not necessary on hvm domain. (How can I find the
> reason here?)
> 
> I don't know if it's ok to add a pair of sysdev_suspend/sysdev_resume inside
> xen_hvm_suspend. If not, this patch can be a quickfix/solution.
> 
> Any ideas on this issue?

In Linus' tree there is 8dd38383a51d "xen: suspend and resume system
devices when running PVHVM" which adds these.

I think it is in xen.git#xen/next-2.6.32 as well now, as of
dfd083bd89b2.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel