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

[Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>]

Just checked this.  Linux does the local APIC EOI on ->ack().

        eSk


[Keir Fraser]
> 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