Re: MSI interrupts

On Wed, 26 Mar 2025 23:48:17 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Wed, 26 Mar 2025 21:35:01 +0000, Scott Lurndal wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:

On Wed, 26 Mar 2025 4:08:57 +0000, Dan Cross wrote:
>

In article <b1c74762d01f71cc1b8ac838dcf6d4fa@www.novabbs.org>,

>

>

                                             Earlier you wrote,
"esmINTERFERENCE is a query on the state of th event and whether
a 2nd party has performed a memory action that kills the event."
Ok, I take this to mean _at the time of the store_, which
appears later in the program.  If it were simply a query at the
time it was written in the code, then it seems like it opens a
TOCTOU bug (what if something interfers after the check, but
before the the locked store at the end?).  Or perhaps it signals
to the architecture that this is the point to which the
processor should rollback, if anything subsequently fails; sort
of a `setjmp` kind of thing that conceptually returns twice.

>
The "if( esmINTERFERENCE() )" not only queries the state of the
participating cache lines, it sets up a guarding-shadow over
the STs to follow such that if killing-interference is detected
none of the STs are performed AND control is transferred to the
branch label (outside of the event). So not only does it query
the state at it execution, it monitors that over the rest of
the event.
>
BUT ALSO: it initializes the ability to NAK SNOOPs. The thought
is that if we have reached the manifestation phase of the event
(that is ready to do all the stores) then we should be able to
drive the event forward by not sending the data in response to
the SNOOP. We send a Nak (based on priority or the data)

>
If you can NAK a snoop, are you then assuming that all DMA is
non-coherent?   That will really piss off the kernel folks.

>
Not at all. DMA is as coherent as the I/O MMU's translating
PTE prescribes.
>
But; why would any sane coder be performing an ATOMIC event on
memory that can be blindly overwritten by DMA ??? Or for that
mater, critical section data being overwritten (at some unknown
and unpredictable time) by DMA ??

>
Polling on a completion status which the device DMAs
(often with an allocate hint) is not uncommon.   A 32-bit
word in memory updated by the device - the allocate hint
might update the LLC directly and invalidate L1/L2 or
may update the target cache line that the driver is
polling directly.

Why do this ATOMICally ?? why not just read it ?? Or is this a
grab (read and modify so someone else doesn't get it.) ??