RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Magenheimer, Dan (HP Labs Fort Collins)
>Sent: 2006年3月10日 2:45
>
>1) Interrupts may happen at a rate of tens of thousands
>   per second.  Just like all high frequency CPU operations
>   are coded with "fast paths" (hyperprivops and hyperreflection),
>   I think interrupt reflection (some call it injection)
>   needs to be implemented with a fast path.  Unlike the
>   CPU ops, there is currently no fast path for external
>   interrupt reflection, though many of the CPU ops that
>   a guest performs (e.g. ivr, eoi, tpr) DO have fast paths.

Yes, interrupt should be implemented with high performance.

>
>   When an external interrupt arrives (e.g. Xen is executing
>   starting at IVT+3000), the vast majority of interrupts
>   should be able to be reflected or recorded using a fast
>   path.  This is much harder to do with event channels than
>   by setting a bit in a hyperregister.  (Sure you could
>   rewrite all the event channel code in assembly, but
>   then what is the point of sharing the C code?)

For this point, I think two paths (by event channel and by interrupt) 
are similar. Once receiving a device interrupt, xen hypervisor goes 
to save cpu state, read ivr, and then jumps to C handler. Then C 
handler (ia64_handle_irq) checks whether that interrupt is owned 
by guest. If yes:
        - Set pending bit in vIRR, and then resume to interrupt handler 
of guest (current behavior), or
        - Set pending bit in evtchn_pending (yes, only one extra array 
lookup), and then resume to callback of guest

In this case, callback is mostly like the interrupt handler of xenlinux, 
with difference that one for event and another for interrupt. So I didn't 
see more difficulty for event channel on this case.

>
>2) Eddie commented that all the event channel code is already
>   used in Xenlinux/ia64.  Not true.  There is a separate
>   file (evtchn_ia64.c) that is used instead.

OK, maybe I should say that's result instead of current status. Once 
we turn to event channel mechanism like x86, the common evtchn.c 
will be reusable by ia64 no change. Previously I already sent out a 
patch to make a small cleanup for evtchn.c

>
>3) I don't think we should be trying to support machines and
>   configurations that Linux is not even yet able to support
>   adequately.  We have plenty of work to do to get Xen/ia64
>   usable.  And sharing IRQs between driver domains may be
>   necessary eventually, but it doesn't seem a huge restriction
>   in the short term to not allow different driver domains to
>   share the same IRQ.
>

I tempt to agree that we may do this complete mechanism step 
by step. For example, we may request Tristan to slim his patch 
first to only contain consensus logic like moving IOSAPIC from 
dom0 to Xen. However he has to hold lines for driver domains like 
RTE sharing, since that part is still in discussion. Also he needs to 
address previous comments on the list about the coding styles.

Then if the new patch is clean enough, it may go in first with discussion 
on rest stuff on-going. 

Thanks,
Kevin

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