lkml.org 
[lkml]   [2013]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory synchronization vs. interrupt handlers
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



\
 
 \ /
  Last update: 2013-08-30 02:01    [W:0.067 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site