| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [Patch] time resolution fix.
On 20 Mar 2006, at 16:08, Dong, Eddie wrote:
Yes, this meets with what Ian and Asit talked in xensummit too. And it
can solve
the TSC calibration issue as wall-clock (RTC) read is some time later
after
TSC calibration. But it has problem in APIC time calibration side, as
it is done very later in Linux (not sure for other OSes), it is even
later than init
thread creation that is hard to determine in xen.
Hmmm.. in fact it looks like Linux reads CMOS RTC before even
calibrating bogomips, so that wouldn't be a good point to disable TSC
freezing after all.
Another issue is that some calibration loops read the PIT counter (and
would be confused by wrapping), or expect to receive timely interrupts
to increment jiffies. Those are hard to guarantee in a virtualised
environment. So there's a general timeliness issue as well as the
original 'delay loop progress' versus 'time progress' issue.
There's no good way out of this I suspect. If guest time is to track
wallclock time then guests are going to have to see time jumping
forward across preemptions, or the jumping is simply going to be saved
up for some time later (eg. as you do currently when the PIT
underflows).
Maybe we should do something really simple like run the guest in
'virtual' (scheduled) time for some number of seconds after boot, then
switch to real time (which runs at an accelerated rate for a short
while to catch back up with real time)?
A better solution to remove this assumption is that we implement a
mechanism like PIT IRQ output line that will discard accumulated IRQs
during
guest IRQ disable time. I.e. if guest IRQ is disabled,
pickup_deactive_ticks
should ignore the elapsed ticks (only add one more pending IRQ). In
this
way
the guest behavior will be exactly same with native. We should put this
in
our TODO list :-)
What effect will this have? Are you suggesting to always run guest time
at 'virtual time' rather than real wallclock time?
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home