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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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" <espen.skoglund@xxxxxxxxxxxxx> 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" <yunhong.jiang@xxxxxxxxx> 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: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
> 
> 
> 



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