Re: [Xen-devel] [Patch] time resolution fix.

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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