xen-ia64-devel
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery
To: |
"Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx> |
Subject: |
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery |
From: |
"Tian, Kevin" <kevin.tian@xxxxxxxxx> |
Date: |
Fri, 10 Mar 2006 03:16:40 +0800 |
Delivery-date: |
Thu, 09 Mar 2006 19:30:04 +0000 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
List-help: |
<mailto:xen-ia64-devel-request@lists.xensource.com?subject=help> |
List-id: |
Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com> |
List-post: |
<mailto:xen-ia64-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe> |
Sender: |
xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
AcZCvtC1wi4TOelcSySjvQqW26qAzAACtJAQADdrVZAAAMbEIA== |
Thread-topic: |
[Xen-ia64-devel] vIOSAPIC and IRQs delivery |
>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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-ia64-devel] vIOSAPIC and IRQs delivery, (continued)
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery, Tian, Kevin
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery, Tian, Kevin
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery, Tian, Kevin
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery, Tian, Kevin
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery, Magenheimer, Dan (HP Labs Fort Collins)
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery,
Tian, Kevin <=
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery, Dong, Eddie
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery, Dong, Eddie
RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery, Tian, Kevin
|
|
|