Keir:
Thanks!
Keir Fraser wrote:
> What effect will this have? Are you suggesting to always run guest
> time at 'virtual time' rather than real wallclock time?
>
Ooo, the new proposal is not focusing on this issue :-)
The basic issue we saw is
1: how to jump guest time
For example, when a SMP system has 2 VPs, each VP APIC time
(VP0-VP1) has a scheduled fire time say at 4ms, and 6ms time.
And the platform time say PIT is scheduled at 8ms time.
when VP0 is descheduled, while VP1 is switched in, then probably
we can't inject APIC time IRQ to VP1 even hypervisor undergo
6ms+ time. Because injecting APIC time IRQ means VP1 saw guest
time jumped to 6ms later and same on TSC (platform). Otherwise when
VP0 is switched in, guest TSC time on VP0 is in 6ms+ later time, but
the ACPI timer ISR is still assuming it is in 4ms time. This kind of
lossing
synchronization means VP0 see backward time that may cause various
corner case like we saw previously in PIT and TSC.
Combining per processor time IRQ with platform time IRQ, the
situation will become much complicated.
2: How to deliver guest time IRQ effeciently.
Same with above situation, if the VP with next scheduled timer
resource
is deactive, all other VP may be unable to get time IRQ. That is unfair
and may
cause no way to catchup in some difficult case :-)
Also if platform time IRQ is pinned on certain VP, that is much
worse :-(
3: Make platform time code object orientation.
That means, no matter RTC, ACPI or PIT time, for each HVM, the
configuration
can choice eithe of them and xen will provide dynamic register APIs. In
this way we
are no longer pinned on PIT.
We have something in mind, but not fully completed yet.
For simplicity, we may assume a) An guest OS only use one of the
platform time as its ticking resource. b) platform time IRQ is not
pinned on
certain VP.
thx,eddie
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home