| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [Patch] time resolution fix.
Keir:
Yes, for future multiple platform time resource
support (RTC, PIT, ACPI), I agree eventually they should be in HV.
> The freezing is I guess why you have the new hook schedule_out(),
> which I'm also not madly keen on. Especially since this must surely
> be a short-term workaround (you don't intend to TSC freeze as
> long-term solution, right?).
It is true that I don't like to freeze the guest time at deschedule
time, but
so far we have to stay here before we find better solution :-(
The reason is in legacy guest PIT ISR (interrupt service routine). The
ISR code
reads TSC and computing the elapsed TSC (compare with saved old TSC)
from last PIT IRQ fire time. If xen doesn't present exactly expected
difference
in TSC, guest may get accumulated difference in PIT ISR and do some
fixup
that is a messy of guest jiffies and complain "lossed tick". Eventually
that
will force guest to give up using TSC as time resource (roll back to
pure PIT).
With this patch, we get very accurate guest time in our local test:-)
Keir Fraser wrote:
> Actually, I now recall we were going to use this approach long term to
> ensure the guest calibrates TSC rate correctly during boot. But then
> we are going to turn it off the first time the guest reads wall-clock
> time (via RTC, for example). But that means we will need the
> schedule_out() hook long term, and that makes your patch less
> unattractive. I'll take another look and reconsider it.
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.
Freezing TSC has similar function with this suggestion. The difference
in freezing
TSC approach is that we need to assume the guest calibration is a
one-time task.
Otherwise the guest may see time backward in runtime.
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 :-)
> In summary, I'm not sure about this patch. I feel that if I take it
> I'm encouraging 'onward and upward' development without spending the
> time to make sure fundamental abstractions like time are designed and
> implemented soundly.
Thanks! We have plan to come out a much complicate time virtualization
design
soon to support multiple platform time resources and SMP better. We saw
several
issues for SMP support in guest time forwarding. We will send the design
out
as soon as possible and collect feedback from you and all others:-)
thx,eddie
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home