Matthew Wilcox wrote:> > I think David's original patch (just declining to mask the interrupt)> is the best approach to take. Perhaps architectures with saner> interrupt hardware would like to try the approach I've mentioned here.> > I don't like the comment in http://lkml.org/lkml/2008/6/27/199 as it's> not prohibited ... just a bad idea. How about this patch?

The PCI specification is quite clear that it's prohibited. The problemalso is more severe than simply having spurious interrupts -- with somedevices if a line interrupt is generated (regardless of whether it endsup on the bus) then no more interrupts are generated.

I also think that the change requires a comment in the code. It odd tohave a mask function that doesn't really mask so a comment is necessaryto explain why this is.

Trying to mask MSIs with the MSI Enable results in some devicesgenerating a line interrupt (which may not appear on the bus if theINTX# Disable bit is set). This interrupt will be lost and somedevices will generate no further interrupts (even after MSI Enable isset again).

The PCI Local Bus Specification Revision 3.0, section 6.8.1.3. MessageControl for MSI on page 236, prohibits the use of the MSI Enable bit formasking and unmasking the interrupt.

"MSI Enable: If 1 and the MSI-X Enable bit in the MSI-X Message Control register (see Section 6.8.2.3) is 0, the function is permitted to use MSI to request service and is prohibited from using its INTx# pin (if implemented; see Section 6.2.4 Interrupt pin register). System configuration software sets this bit to enable MSI. A device driver is prohibited from writing this bit to mask a function’s service request."

There is no alternative method for mask/unmask on PCI devices with MSIand no specific mask bit. In this case, the device driver will haveto ensure that MSIs are only generated when the device driver canhandle them (via some hardware specific mechanism such asacknowledging the interrupt at the end of the interrupt handler) .