Add Stefano Stabellini, who made the commit of xen_hvm_suspend in the git tree.
Stefano, do you have any idea?
On Tue, Mar 22, 2011 at 12:19 PM, Frank Pan <frankpzh@xxxxxxxxx> 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?
>
> --
> 潘震皓, Frank Pan
>
> Computer Science and Technology
> Tsinghua University
>
--
潘震皓, Frank Pan
Computer Science and Technology
Tsinghua University
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|