[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |