Clarify interaction of xithreshold and interrupt file eithreshold.

[mark-honman]

The AIA eithreshold, eip, eie, etc. indirect registers are defined within an interrupt file that is only accessible via the CSRs miselect/miregX for the machine mode interrupt file, siselct/siregX for the supervisor-mode interrupt file.

Section 5 covering Smnip and Ssnip each introduce 3 new CSRs

• mithreshold / sithreshold
• mipreemptcfg / sipreemptcfg
• mpistatus / spistatus

Is mithreshold intended to be an alias of the eithreshold register of the M-mode interrupt file, and sithreshold for S-mode?

I can sort of see how this makes sense because mpistatus needs to be saved in a preemptible interrupt handler, and if it were an indirect CSR that would require an extra instruction to write miselect. And then if mpistatus is a direct CSR and contains field that reflect CSR values in the OIC, it would seem odd that the OIC threshold comes from an indirect CSR.

On the other hand AIA does not provide for an M-mode threshold, and AIA mtopi is not affected by any thresholds because no threshold affects major interrupts [would that cause any problems in embedded applications - I think not, if there is a convention that major interrupts are preemptible but cannot themselves preempt - other than the externel interrupt].

But - if mithreshold and eithreshold are different registers that would also make sense, except that then it likely becomes necessary to save eithreshold of the OIC.

However mipreemptcfg could easily be an indirect CSR, and the AIA interrupt-file indirect CSR map has free entries either side of eithreshold.