| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH] [Bugfix][pv-ops] Guest get stucked after migrati
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
|
|
|
| |
|
Home