From: chris.m.thomasson.1@gmail.com   
      
   On 12/8/2025 9:14 AM, Scott Lurndal wrote:   
   > Stephen Fuld  writes:   
   >> On 12/8/2025 4:25 AM, Robert Finch wrote:   
   >>>    
   >   
   >>> I am having trouble understanding how the block of code in the   
   >>> esmINTERFERENCE() block is protected so that the whole thing executes as   
   >>> a unit. It would seem to me that the address range(s) needing to be   
   >>> locked would have to be supplied throughout the system, including across   
   >>> buffers and bus bridges. It would have to go to the memory coherence   
   >>> point. Otherwise, some other device using a bridge could update the same   
   >>> address range in the middle of an update.   
   >>   
   >> I may be wrong about this, but I think you have a misconception.  The   
   >> ESM doesn't *prevent* interference, but it *detect* interference.  Thus   
   >> nothing is required of other cores, no locks, etc.  If they write to a   
   >> "protected" location, the write is allowed, but the core in the ESM is   
   >> notified, so it can redo the ESM protected code.   
   >   
   > Sounds very much similar to the ARMv8 concept of an "exclusive monitor"   
   > (the basis of the Store-Exclusive/Load-Exclusive instructions, which   
   > mirror the LL/SC paradigm).  The ARMv8 monitors an implementation defined   
   > range surrounding the target address and the store will fail if any other   
   > agent has modified any byte within the exclusive range.   
      
   Any mutation the reservation granule?   
      
      
      
   >   
   > esmINTERFERENCE seems to require multiple of these exclusive blocks   
   > to cover non-contiguous address ranges, which on first blush leads   
   > me to worry both about deadlock situations and starvation issues.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)