On Thu, March 21, 2013 11:33 am, Joel Hestness wrote: > Hey guys, > Ali's assessment is correct, namely, that higher priority interrupts can > be dropped if the x86 interrupts device receives a low priority interrupt > followed by a high priority interrupt before either is serviced. From > what > I recall, this problem is unique to x86, because it is the only > architecture gem5 supports that allows multiple concurrent interrupts. > This means that you can consider servicing interrupts out of order - in > this case, servicing the higher priority interrupt first - unlike other > architectures, which will service the interrupts in FIFO order. > > @Nilay: > Your solution is definitely a step in the right direction, but I think > we > should go a step farther, because this will still instantiate and drop > fault object instances with the interrupt pointer. Yes, faults are > ref-counted, but we don't even need to instantiate them: Your solution > reduces the commit stage interrupt pointer to a bool which indicates > whether there is an interrupt pending. Why not replace the pointer with a > bool, say "interruptPending", which is used to signal whether an interrupt > is pending instead of the interrupt pointer being non-NULL for all gating > in the commit pipeline? Instead of calling getInterrupts() as we do > currently and having commit hang onto a fault instance with the interrupt > pointer, the O3CPU should call a different (new) interrupts device > interface function isInterruptPending(), which returns a bool if there is > an interrupt to service. This would greatly clarify the use of these > variables in the commit stage and it would reduce the risk of future code > modifications that mishandle the interrupt pointer. The obvious downside > of this solution is that it will require updating the interrupts devices > for every architecture, which may be a fair amount of work, and testing > these changes is very non-trivial.
Note that the function for checking whether or not interrupts are pending already exists. It is called checkInterrupts(). But the suggested solution will not work for the alpha architecture. This is because in alpha, the functions checkInterrupts() and getInterrupts() do not always agree. -- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
