Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Wed, 26 Mar 2025 23:22:35 +0000
Organization: Rocksolid Light
Message-ID: <3061a58cdec38c3aa6093cbb74ea004a@www.novabbs.org>
References: <vqto79$335c6$1@dont-email.me> <e4ecfb53ef4f33f10b6d2548d5930159@www.novabbs.org> <vrva4r$9ka$1@reader1.panix.com> <b1c74762d01f71cc1b8ac838dcf6d4fa@www.novabbs.org> <vrvukp$n29$1@reader1.panix.com> <7a093bbb356e3bda3782c15ca27e98a7@www.novabbs.org> <9q_EP.688441$SVG3.221243@fx42.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1899125"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Rslight-Site: $2y$10$A9TU0VE3fiV5ad03MIZmauDx1LRZCwyG/hlazAWsegJp4x05PGmmy
Bytes: 3318
Lines: 43

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 ??