From: user5857@newsgrouper.org.invalid   
      
   Stephen Fuld  posted:   
      
   > On 11/29/2025 6:29 AM, Robert Finch wrote:   
   > > I hard-coded an IRQ delay down-count in the Qupls4 core. The down-count   
   > > delays accepting interrupts for ten clock cycles or about 40   
   > > instructions if an interrupt got deferred. The interrupt being deferred   
   > > because interrupts got disabled by an instruction in the pipeline. I   
   > > guessed 40 instructions would likely be enough for many cases where IRQs   
   > > are disabled then enabled again.   
   > >   
   > > The issue is the pipeline is full of ISR instructions that should not be   
   > > committed because the IRQs got disabled in the meantime. If the CPU were   
   > > allowed to accept another IRQ right away, it could get stuck in a loop   
   > > flushing the pipeline and reloading with the ISR routine code instead of   
   > > progressing through the code where IRQs were disabled.   
   > >   
   > > I could create a control register for this count and allow it to be   
   > > programmable. But I think that may not be necessary.   
   > >   
   > > It is possible that 40 instructions is not enough. In that case the CPU   
   > > would advance in 40 instruction burps. Alternating between fetching ISR   
   > > instructions and the desired instruction stream. On the other hand, a   
   > > larger down-count starts to impact the IRQ latency.   
   > >   
   > > Tradeoffs…   
   > >   
   > > I suppose I could have the CPU increase the down-count if it is looping   
   > > around fetching ISR instructions. The down-count would be reset to the   
   > > minimum again once an interrupt enable instruction is executed.   
   > >   
   > > Complex…   
   >   
   > A simple alternative that I have seen is to have an instruction that   
   > enables interrupts and jumps to somewhere, probably either the   
   > interrupted code or the dispatcher that might do a full context switch.   
   >   The ISR would issue this instruction when it has saved everything that   
   > is necessary to handle the interrupt and thus could be interrupted   
   > again.  This minimized the time interrupts are locked out without the   
   > need for an arbitrary timer, etc.   
      
   Another alternative is to allow ISRs to be interrupted by ISRs of higher   
   priority. All you need here is a clean and precise definition of priority   
   and when said priority gets associated with any given interrupt.   
      
   My 66000 goes so far as to never need to disable interrupts because all   
   interrupts of the same or lower priority are automatically disabled by   
   the priority of the current ISR/running-thread. That is, one arrives   
   at the ISR with interrupts enabled and in a reentrant state with the   
   priority given by the I/O MMU when device sent ISR message to MSI-X   
   queue.   
      
   If/when an ISR needs to be sure it is not interrupted, it can change   
   priority in 1 instruction to "highest" and have the system not allow   
   the I/O MMU to associate said "exclusive" priority with any device   
   interrupt. When ISR returns, priority reverts to priority at the time   
   the interrupt was taken. {No need to back down on priority} This only   
   requires that there are enough priorities to spare one exclusively to   
   the system.   
      
   EricP has argued that 8-I/O priority levels are enough. I argue that   
   64 priority levels are enough for {Guest OS, Host OS, HyperVisor}   
   to each have their own somewhat-coordinated structure of priorities.   
   AND further I argue that given one is designing a 64-bit machine,   
   that 64 priority levels are dé rigueur.   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)