On Wed, Aug 28, 2013 at 01:28:08PM -0700, H. Peter Anvin wrote:
> On 08/28/2013 12:16 PM, Alan Stern wrote:
> > Russell, Peter, and Ingo:
> >
> > Can you folks enlighten us regarding this issue for some common
> > architectures?
>
> On x86, IRET is a serializing instruction; it guarantees hard
> serialization of absolutely everything.
So a second interrupt from this same device could not appear to happen
before the IRET, no matter what device and/or I/O bus? Or is IRET
defined to synchronize all the way out to the whatever device is
generating the next interrupt?
> I would expect architectures that have weak memory ordering to put
> appropriate barriers in the IRQ entry/exit code.
Adding a few on CC. Also restating the question as I understand it:
Suppose that a given device generates an interrupt on CPU 0,
but that before CPU 0's interrupt handler completes, this device
wants to generate a second interrupt on CPU 1. This can happen
as soon as CPU 0's handler does an EOI or equivalent.
Can CPU 1's interrupt handler assume that all the in-memory effects
of CPU 0's interrupt handler will be visible, even if neither
interrupt handler uses locking or memory barriers?
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
