RE: [Xen-devel] [PATCH 0/5] Add MSI support to XEN

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

Not masking each time when interrupt happen, instead, we do that only
when the second interrupt happen while the previous one is still
pending, it should be something like handle_edge_irqs() in upstream
linux.

-- Yunhong Jiang

Espen Skoglund <mailto:espen.skoglund@xxxxxxxxxxxxx> wrote:
> Preventing interrupt storms by masking the interrupt in the MSI/MSI-X
> capabilty structure or MSI-X table within the interrupt handler is
> insane.  It requires accesses over the PCI/PCIe bus and is clearly
> something you want to avoid on the fast path.
> 
>       eSk
> 
> 
> [Haitao Shan]
>>     There are no much changes made compared with the original
patches.
>> But there do have some issues that we need your kind comments.
> 
>>   1> ACK-NEW method is necessary to avoid IRQ storm. But it causes
the
>>          deadlock. During my tests, I do find there can be deadlock
with
>> patches applied. When assigned a NIC device to HVM domain, the
scenario
>> is: Dom0 is waiting to IDE interrupt (vector 0x21); HVM domain is
waiting
>> for qemu's IDE emulation and thus blocked; NIC interrupt (MSI vector
0x31)
>> is waiting for injection to HVM domain since it is blocked now; IDE
>> interrupt is waiting for NIC interrupt since NIC interrupt is of high
>> priority but not ACKed by XEN now. When IDE interrupt and NIC
interrupt
>> are delivered to the same CPU, and when guest OS is Vista, the
>> phenomenon is easy to be observed.
> 
>>   2> Without ACK-NEW, some naughty NIC devices as we observed will
>> bring IRQ storms. For this phenomenon, I think Yunhong can comment
more.
>> Basically, writing EOI without mask the source of MSI will bring IRQ
>> storm. Although the reason is under investigation, XEN should anyhow
>> handle such bogous device, right?
> 
>>   3> Using ACK-OLD and masking the MSI when writing EOI can be
>> solution. However, XEN does not own PCI configuration spaces.

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