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

RE: [Xen-devel] [Patch] Fix the slow wall clock time issue in x64SMP Vista

  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Wed, 10 Jan 2007 22:42:09 +0800
  • Delivery-date: Wed, 10 Jan 2007 06:42:41 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acc0qpECUWE/uVerTTS+WkRpZ1GU0QAAQ2zNAABGKxAAAJtwjAAFRSLg
  • Thread-topic: [Xen-devel] [Patch] Fix the slow wall clock time issue in x64SMP Vista

> I cannot see the logic behind the change though. If the guest has set
> up a timeout, and the timeout is in the past, it makes sense to
> deliver immediately.
Basically I agree too, but the problem is that how can we determine it
is a past time?
>From HW point of view, it doesn't think it is a "past" time, so it will
think it is a time long ahead.
HPET spec mentions that SW should set a comparator far enough to avoid
HW see a "past" time set. But in our virtualization environment, it
could become a "past" time due to overhead of virtualization cost. Thus
putting a threshold for this situation may help us.

Because HPET is very similar with IA64 ITC timer, in IA64 Linux, the OS
will try to read back the counter after comparator setting (ITC or TSC
in X86) to make sure it is before the set comparator, otherwise reset
with a new comparator. Not sure how Windows HPET handle this, but
probably we can assume similar mechanism in OS.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.