From: robfi680@gmail.com   
      
   Background TLB flushing via HW state machine? I am not sure about the   
   merits of this approach. Because the TLB is implemented using BRAM the   
   valid bits are not individually accessible. The design is too low cost   
   to support a separate valid bit array. Therefore, to flush the entire   
   TLB there is a background process *1 that reads the TLB entries, clears   
   the valid bit then writes it back to the TLB.   
      
   *1 a couple of states in the page walking state machine.   
      
   The automatic flushing for the entire TLB in HW allows translations to   
   continue to take place while the background HW process runs. If the   
   entire TLB needs to be flushed, a master TLB count is incremented. TLB   
   entries are considered valid only if the entry count matches the master   
   TLB count. The background process invalidates TLB entries where the   
   entry count does not match the TLB count.   
      
   As long as the background process can cycle through (on average) all the   
   TLB entries before the TLB is flushed again there should be no issues   
   with stale translations. The master TLB count is a six-bit counter. The   
   flush cycle rate can be controlled. Setting the rate to zero disables   
   automatic flushes. Setting it to all ones flushes at the maximum rate,   
   effectively disabling translations while the flush takes place.   
      
   It may be an option to not automatically flush global translations.   
      
   Read up on the TLB in the Linux docs. It seems the TLB may be entirely   
   flushed or flushed page by page. Thinking about doing the page-by-page   
   flush as background HW process. Flush all the entries matching an ASID.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)