[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-ia64-devel] RE: Xen-ia64-devel Digest, Vol 11, Issue 22
- To: "Luck, Tony" <tony.luck@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
- From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
- Date: Fri, 10 Feb 2006 11:56:31 -0800
- Delivery-date: Fri, 10 Feb 2006 20:07:49 +0000
- List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
- Thread-index: AcYuK2BYTZdSlj7yQ7+1jCQnmgWKdgATQKDwAADWZHA=
- Thread-topic: [Xen-ia64-devel] RE: Xen-ia64-devel Digest, Vol 11, Issue 22
> > > > What should we do ?
> > > > a) virtualize ITC
> > > > b) para-virtualize ITC (ie, modifying linux kernel)
> > > > c) pre-synchronize ITC
> > > >
> > > > I really prefer c).
> > >
> > > I'm not sure I understand c). Aren't the ITCs already
> > > pre-synchronized by xen in smp_callin()? Thanks,
> > Correct, but Linux is not aware of this.
> > After more thoughs, I really think this is the best solution.
> 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.)
Xen-ia64-devel mailing list