RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

[Williams, Mitch A]

Eric W. Biederman wrote: 
>
>> Because enabling and disabling the MSI interrupt is done through
>> config space, and config space writes are not posted.  So we won't
>> see the problem that we do with MSI-X.
>
>Normally this is true.  However when we have  memory mapped pci config
>space the writes could very easily be posted.  Even if there aren't
>any Intel platforms that do it today other architectures might.

>From what I read in the spec, configuration writes are not ever posted.
They are a completely separate transaction type from memory writes, and
only memory writes are posted.  So there's no need to read-flush these.

>The more I think about this the more I think we should make mask and
>unmask do the read and set enable/disable to mask/unmask in the msi
>case.
>
>I think being a little more paranoid will result in slightly simpler
>more maintainable code, and not measurably affect performance.  I
>don't expect you are migrating irqs in a fast path.

Migrating IRQs happens in the fast path, but infrequently (every 10 
seconds or so).  However the mask function is called at EVERY interrupt,
so this change would be VERY expensive.

If the driver really needs to disable the interrupt, then it can call
irq_disable().  Otherwise, mask (as-is) should be fine -- it masks
the interrupt at the APIC, and the device's interrupt moderation
should take care of keeping it from generating interrupts right away.

-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/