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

["Caitlin Bestler" <Caitlin.Bestler@xxxxxxxxxxxx>]

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
> 

I agree. Interrupt mitigation schemes should already be part of the
host/device interface that is being assigned to the HVM guest. The
HVM guest should already know how to use it.

> 
> [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?
> 

Device assignment should deliver the device to the HVM, with all of its
warts as well as all of its features. Isn't the ultimate point is to use
the same driver in the HVM guest whether Xen is present or not?


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