[Xen-ia64-devel] RE: Timer merge

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

>       Wonderful discussion between you and kevin. Just add 
> more comments here.

Yes, it's nice to have a real meaty technical discussion
again.
 
> > Not just the fast path for reflection (once per tick).  Also
> > the fast path for reading ivr (twice per tick), setting tpr
> > (once per tick), reading tpr (twice per tick), setting eoi
> > (once per tick), and (of course) setting itm (once per tick).
> For TPR, IVR/EOI, yes it can be done in ASM with payment in 
> readability and we'd better do in that way.
> But we are paying security here because we skipped the 
> permission check in ASM. 
> For example, if guest application want to do hypercall 
> through break instruction(PSR.ic=1), the HV is not block this 
> kind of operation. If you consider the permission check code 
> for each fast hypercall, the overhead is much higher.

Not true.  The fast hypercall path only gets executed if
virtual psr.ic is off.  A guest application cannot turn
off virtual psr.ic as the shared page (memory-mapped
virtual privileged registers) is not accessible at PL=3.

> > These nine operations total ~1000 cycles when using the fast
> > path and ~15000 when using the slow path.  Multiplied by
> > 1024 hz, the slow path uses an additional (above what
> > Linux uses) ~1.5% of the total CPU just processing clock ticks.
> 
> The previous proposal only targets on machine ITM set stuff. 
> So performance degradation is much small than 1.5%.
>  :
> If we keep the guest ITM, the performance difference 
> calculated above is further decreased to 1.5%*1/9=0.16% :-)
> We have achieved the goal now!!!

Yes, this seems reasonable.  But let's work to ensure that
the setting of itm is still as fast as possible, e.g. no
walking down long linear linked lists. :-)

> We booted both Linux & Windows Server 2003 on VMM, both of 
> them are OK with that. Also when the VM # increase, it is a 
> must for guest to catch up itself.
> In IA32, the PIT IRQ is stacked when the domain is switched 
> out, and inject one by one when the domain is switched back. 
> In IPF, we can take the advantage of batching interrupt 
> processing mechanism.

So Xen/x86 delivers every timer tick to every Linux domain?
That seems like a potential performance problem!

> So we reach common point here to keep an guest ITC by delta.
> Another thing is that I think we need to keep a guest ITM. 
> Suppose Dom1 program its ITM to machine itm in current 
> implementation, some time later before the timer is expired, 
> an IO operation in Dom1 causes domain switch (do_block). The 
> control is switched back to Dom0, the machine ITM must be 
> reprogrammed to Dom0 next ITM. Without pre-saved guest ITM, I 
> am not sure how can this be achieved.

Yes, I think we are agreed on keeping the guest ITC by delta.
Yes, the guest itm must be saved, if only because the guest
can read it back and expect to get the last value it set.
And yes the itm needs to be reprogrammed at domain switch.
 
Dan

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