From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/5] Add MSI support to XEN Date: Fri, 28 Mar 2008 11:53:16 +0000 Message-ID: References: <18412.55422.710799.315672@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <18412.55422.710799.315672@gargle.gargle.HOWL> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Espen Skoglund Cc: "Tian, Kevin" , xen-devel , "Jiang, Yunhong" , "Shan, Haitao" , Keir Fraser , "Li, Xin B" List-Id: xen-devel@lists.xenproject.org I think Linux EOIs on ->end() not on ->ack(). Which is fine since Linux doesn't defer or otherwise schedule ISR handlers. -- Keir On 28/3/08 11:37, "Espen Skoglund" wrote: > That is true. I was quite puzzled with the requirement of the > callback into Xen myself. In standard Linux MSI interrupts are > treated as edge triggered and are just acked in the local APIC upon > delivery. > > eSk > > > > [Keir Fraser] >> 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" 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 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@lists.xensource.com >>> http://lists.xensource.com/xen-devel > > >