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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Jeudi 09 Mars 2006 20:16, Tian, Kevin a écrit :
> From: Magenheimer, Dan (HP Labs Fort Collins)
[...]
> >   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.
Dan is just saying interrupt injection was easier to optimize in asm.
You want to use event channel for convergence.  But if you are ready to 
optimize it in asm, this is divergence.

> >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
Correct for me.

> >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.
Ok, I am ready to rework my patch to handle driver domains and IRQ sharing 
using almost the same code as in x86.
Do you agree with this first step.

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


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