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

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Alex Williamson wrote:
> On Wed, 2006-03-08 at 12:00 -0800, Magenheimer, Dan (HP Labs Fort
> Collins) wrote:
>>>    We agree IOSAPIC must belong to Xen.  And it should be able to
>>> deliver interrupts to domains and handle shared IRQs.
>> 
>> Did I miss an answer to Tristan's earlier question,
>> which was approximately: How many systems out there
>> require shared IRQ's?  I realize there are some huge
>> mainframe-class boxes that have hundreds of I/O cards
>> that probably do require shared IRQ's, but I wonder
>> if this class of machine will even consider using
>> Xen?  Mainframe-class machines have other partitioning
>> technologies with customer-expected features that Xen
>> will never have (such as hardware fault containment).
> 
>    Hopefully I'm not stepping into a rat-hole here, but what are we
> defining as a shared IRQ?  If we're only talking about running out of
> external interrupt vectors on the CPU and programming multiple IOSAPIC
> RTEs to trigger the same vector, I agree.  That case requires are
> rather large system.  Eventually we should support this, but things
> like interrupt domains may be a better long term solutions.

Thanks!
The problem is that Xen already support it by default, the solution is
already there.
What we do is just to use it :-) Linux already support this !
Then why IA64 want to remove this support and leave an extra effort to
future.
If it is a new one, I would say yes we should start from simple.

> 
> Then the third question:  Is there a performance
> cost for shared IRQ support, even on systems that
> don't share IRQ's?  Is there an additional
> performance cost for sharing an IRQ across domains?
> With each NIC card capable of generating thousands
> of interrupts/second, it doesn't seem wise to
> add additional overhead to every interrupt on
> every Xen system to support the possibility that
> someone may want to configure a system to share
> IRQs across domains.

The extra overhead cost in shared IRQ support approach is 0. When this
IRQ
 is not shared, xen just inject it into guest, no extra logic. Event
channel
based pirq handling is much faster than vIOSAPIC based solution as we
have
 conducted in previous discussion.


Some basic conclusion from previous mail include:
1: Event channel based solution has better performance than vIOSAPIC. 
The detail amount is hard to say now, and should depend on benchmark
tool.

2: Event channel based solution can support shared IRQ lines amongst
domains
without any extra logic.

3: Stability:
Event channel based solution has undergone long time well test and real
deployment, 
but vIOSAPIC is not. BTW, IRQ is very important in OS, a race condition
issue may
cost people weeks or even months debug effort.

Some statement people are still arguing:
4: Which one change linux less ?
    My answer is still event channel based solution, as all event
channel code are xen common and 
is already in (VBD/VNIF use it).

5: Which one is much transparent?
   Event channel based solution only needs to do in initial time using
if running_on_xen 
to choice different type hardware interrupt object (i.e. pirq_type vs,
iosapic level_irq_type
 and edge_xxx). After that no extra code.
  vIOSAPIC need to check runtime for every IOSAPIC MMIO access.

6: Stability of future:
   My answer is clear, fixing an intial time bug only costs one-tenth of
runtime bug. Eventchannel
based solution only change intial time code.

Hope this be helpful, thx
Eddie

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