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

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

>From: Magenheimer, Dan (HP Labs Fort Collins)
>Sent: 2006年3月9日 4:01
>
>>    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).

I would be more optimistic about all possibilities, especially when we 
realize it and the support doesn't adding obvious overhead. For this 
case, then I think the logic should be there from the start of reshuffle 
since we're aware. ;-)

>
>Then the second question is: even if shared IRQ
>support must be implemented in Xen/ia64, is there
>really a need for two different domains to share
>an IRQ?  I'd imagine the need for this would be
>very close to zero.

One example is PCI device, with multiple instances may share one irq 
line. If we assign two PCI devices wired on same irq line to different 
domain, your imagination will become true. Though not sure whether 
device assignment can be made at such a granularity in current stage, 
it's still possible to see in near future. People are already talking about 
device sharing after the enhancement of Intel VT-d. There may be multiple 
functions, or multiple queues residing in single PCI device, and one device 
may be presented in different configuration spaces. The virtualization 
eco-system is becoming more mature. We should try to ensure architecture 
correctness to the maximum from the very start, especially when we know 
it's an issue.


>
>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.
>
>My two cents,
>Dan
>
>

Again, the overhead to support irq sharing should be negligible, if we do 
it right at irq level like current xen/x86. Eddie already talks about the 
sequence to handle irq sharing in previous mail:

If this is a guest IRQ, for each domain bund with this IRQ, 
Loop:
                { send event channel to inform guest;
desc->action->in_flight++; }
                Done;   // Notice: here there is no irq_desc->handler->end()

If the irq is not shared, the loop will stop once the only domain completes 
its handle and writes notification to xen. As you see here, simply logic easy 
to support :-)

Thanks,
Kevin

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