RE: [Xen-ia64-devel] RE: Xen-ia64-devel Digest, Vol 11, Issue 22

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Alex Williamson wrote:
> On Fri, 2006-02-10 at 11:56 -0800, Magenheimer, Dan (HP Labs Fort
> Collins) wrote:
>>> 
>>> What if you are running on h/w where ITC cannot be synchronized
>>> because different cpus are driven from different clock sources?
>>> See IA64_SAL_PLATFORM_FEATURE_ITC_DRIFT.
>>> 
>>> Solution d) might be to tell the guest that itc isn't syncronized
>>> (even on systems where it could be).
>> 
>> Cool.  I wasn't aware of this feature.  What are the
>> ramifications to an SMP OS (or in this case SMP guest)
>> if itc isn't synchronized?  (I see the comment in time.c,
>> just not sure I fully understand the user-visible impact.)
> 
>    Another time source is required for the time interpolator in that
> case.  This is often an HPET or platform specific time source.
> 
I second Alex that we should support full ITC virtualization that
provides best flexbility and architecture correctness. In the meantime,
as VTI domain guest will reset ITC, so the ITC ful virtualization is a
must and is already done there. Supporting different frequency of ITC
source is previously considered in VTI design that can be simply solved
by introducing an non 1 factor.  
A much more crucial fact to support full ITC virtualization is how to
avoid guest time out that I believe current non-VTI timer virtualization
approach has potential correctness issues. Taking an example of a 20 VMs
running on an UP environment case, a guest processor may be scheduled
out for 200ms if the scheduler quantum is 10ms (current Xen situation)
and assume the scheduler using round robin policy. If a guest device or
application is expecting an action (such as IDE read) to be done within
100ms (timeout). Without ITC virtualization, the guest see the direct
host ITC jump (200ms) due to domain schedule happened and immediately
timeout (although the action may be also completed at that time). With
ITC full virtualization, this can be solved by introducing a temp drift
that let guest see not that much jump in one time (becomes several small
jump). This approach existed to in our previous IPF VMM project (at the
similar time with vBlade) to solve this problem.

Thx,Eddie 

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel