[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.