41 messages in com.xensource.lists.xen-develRe: [Xen-devel] [PATCH 0/5] Add MSI s...| From | Sent On | Attachments |
|---|---|---|
| Shan, Haitao | 26 Mar 2008 23:55 | |
| Shan, Haitao | 26 Mar 2008 23:59 | .patch |
| Shan, Haitao | 27 Mar 2008 00:01 | .patch |
| Shan, Haitao | 27 Mar 2008 00:03 | .patch |
| Shan, Haitao | 27 Mar 2008 00:03 | .patch |
| Shan, Haitao | 27 Mar 2008 00:04 | .patch |
| Shan, Haitao | 27 Mar 2008 00:10 | .patch |
| Keir Fraser | 27 Mar 2008 00:55 | |
| Espen Skoglund | 27 Mar 2008 10:32 | |
| Caitlin Bestler | 27 Mar 2008 15:09 | |
| Jiang, Yunhong | 27 Mar 2008 18:48 | |
| Keir Fraser | 28 Mar 2008 00:24 | |
| Jiang, Yunhong | 28 Mar 2008 01:39 | |
| Keir Fraser | 28 Mar 2008 01:51 | |
| Keir Fraser | 28 Mar 2008 02:15 | |
| Tian, Kevin | 28 Mar 2008 02:22 | |
| Keir Fraser | 28 Mar 2008 02:32 | |
| Jiang, Yunhong | 28 Mar 2008 02:35 | |
| Jiang, Yunhong | 28 Mar 2008 02:37 | |
| Keir Fraser | 28 Mar 2008 02:45 | |
| Tian, Kevin | 28 Mar 2008 02:48 | |
| Keir Fraser | 28 Mar 2008 03:00 | |
| Shan, Haitao | 28 Mar 2008 03:02 | |
| Keir Fraser | 28 Mar 2008 03:08 | |
| Shan, Haitao | 28 Mar 2008 03:12 | |
| Espen Skoglund | 28 Mar 2008 04:37 | |
| Keir Fraser | 28 Mar 2008 04:52 | |
| Espen Skoglund | 28 Mar 2008 05:00 | |
| Espen Skoglund | 28 Mar 2008 05:15 | |
| Keir Fraser | 28 Mar 2008 05:59 | |
| Jiang, Yunhong | 31 Mar 2008 06:57 | |
| Keir Fraser | 31 Mar 2008 07:13 | |
| Keir Fraser | 31 Mar 2008 07:15 | |
| Jiang, Yunhong | 31 Mar 2008 07:25 | |
| Keir Fraser | 31 Mar 2008 07:33 | |
| Shan, Haitao | 31 Mar 2008 19:38 | |
| Neil Turton | 02 Apr 2008 07:55 | |
| Shan, Haitao | 03 Apr 2008 05:11 | |
| Keir Fraser | 03 Apr 2008 05:31 | |
| Shan, Haitao | 30 Apr 2008 00:10 | |
| Shan, Haitao | 30 Apr 2008 00:17 |
| Subject: | Re: [Xen-devel] [PATCH 0/5] Add MSI support to XEN![]() |
|---|---|
| From: | Keir Fraser (keir...@eu.citrix.com) |
| Date: | 03/28/2008 12:24:27 AM |
| List: | com.xensource.lists.xen-devel |
This requires the guest to call back into Xen to signal EOI (as we already do for legacy level-triggered interrupts). We shouldn't really need to do that for MSI and it's rather more expensive than a couple of accesses over the PCI bus!
It's this callback into Xen, which we do not really understand why it's needed, which I'm railing against. Is there some fundamental aspect of MSI we do not understand, or are we working around one brain-dead or buggy device?
-- Keir
On 28/3/08 01:48, "Jiang, Yunhong" <yunh...@intel.com> wrote:
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:espe...@netronome.com> 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-...@lists.xensource.com http://lists.xensource.com/xen-devel
_______________________________________________ Xen-devel mailing list Xen-...@lists.xensource.com http://lists.xensource.com/xen-devel





.patch