riscv-fast-interrupt
riscv-fast-interrupt copied to clipboard
riscv
proposal to replace clicintattr.mode with xcliccfg.xlvl
Separating out priv proposal from issue #96 TG meeting discussed this proposal:
Replace nmbits and nlbits fields with:
mcliccfg.mlvl
scliccfg.slvl
xlvl values are encoded 0 ... 255 (only the most-significant CLICINTCTLBITS are writable in the 8-bit field). Values are encoded as for clicintctl (i.e., unimplemented LSBs are hardwired to 1s).
xlvl field values are absolute level numbers (not relative to mode).
mlvl is lowest level that traps into m-mode. If mlvl=0 all interrupts trap into M-mode. If U-mode is not implemented (implying S-mode is also not implemented), then mlvl=0.
If S-mode is implemented, slvl is lowest level that traps into s-mode. mlvl has priority over slvl, so if mlvl<=slvl no interrupts trap into s-mode. If slvl=0, no interrupts trap into u-mode. If U-mode interrupts are not implemented, then slvl=0.
If U-mode interrupts are implemented, then interrupts <slvl trap into U-mode.
Operation:
The interrupt tree determines the highest-numbered pending-and-enabled interrupts, based on value in clicintctl bits treated as an unsigned integer.
If the value is >= mlvl, the trap is taken in M-mode. otherwise if supervisor mode is implemented and the value is >= slvl, the trap is taken in S-mode otherwise if user-mode interrupts are implemented the trap is taken in U-mode
Feb 28: Is this an issue with using xlvl (I'm calling priv_thresh below) to set the privilege of the interrupt?
Since mcliccfg sets the level at which interrupts are m-mode, s-mode attempts to write clicintctl[i] above mcliccfg.priv_thresh should fail because we don't want s-mode to be able to change configuration of an interrupt to m-mode. But with attempts at writing clicintctl[i], SW can determine the higher privilege priv_thresh value. Is this a problem?
Mar 13 Benefits to proposal to replace nmbits and nlbits fields with mcliccfg.mlvl and scliccfg.slvl:
with m and 1 other mode supported, there is the possibility of saving1 implemented flop per interrupt (e.g. m has 4 and u has 12. no savings if m has 5 and u has 12. no savings if m has 8 and u has 8. with m and 2 other modes supported, save at least 1 implemented flop per interrupt and it is possible to save 2 flops per interrupt if the packing works out right. Interrupts are often not evenly distributed between modes. expect that in many implementations, u or s-mode will have significantly more interrupts than m-mode so the possibility of savings on implementations may be a common implementation occurrence. (However, while m-mode interrupts may need to be carefully prioritized, u or s-mode may be able to group many interrupts into the same interrupt levels. Not clear how significant this benefit really is....) Disadvantages to proposal:
interrupt levels have to be coordinated/allocated between modes. software from different groups or different companies have to know how many levels are allocated to each mode. If one mode needs to increase the allocation, other SW for other modes may need to be modified and updated. Biggest flop savings occurs on designs with many interrupt levels/many interrupts. Those designs probably aren't as sensitive to the flop count as smaller designs. Reduces that max number of interrupt levels (e.g. can't have 255 m-mode, 255 s-mode, 255 u-mode levels. limited to m-mode + s-mode +u-mode levels<=255 (because mintthresh/minstatus is 8 bits). would this make adding hypervisor support to CLIC more difficult? Seems messy to need to allocate interrupt levels for hypervisor mode when existence of hypervisor should be invisible to lower priv modes. CLIC would probably need a attr.mode bit to hide hypervisor instead of messing with interrupt levels.
3/29 The new proposal would have to ensure supervisor cannot reconfigure an interrupt's settings (clicintattr) then change that interrupt's level (clicintctl) above current mlvl such that M-mode receives interrupts with a configuration it was not expecting. M-mode code could be designed to cope with any configuration, though this seems burdensome.
Alternatively, we can prevent S-mode aperture writes to clicintctl from writing >=mlvl. This is not sufficient by itself, since there is state in the CLIC. If mlvl is changed, M-mode code must also scan through all clicintctl level settings and reset to <mlvl.
current interrupt priority reduction tree: concatenate clicintattr.mode,clicintctl and pick highest value of pending and enabled interrupts select xcliccfg register based on mode of highest value and calculate which bits are priority and which bits are level based on xcliccfg.nlbit setting. if the winner priv mode > current priv mode, then take interrupt, else: if mode of winner of priority reduction tree equals current priv mode, compare calculated level with xintthresh and xintstatus of current priv mode.
proposed interrupt priority reduction tree: pick highest clicintctl of pending and enabled interrupts. use mcliccfg.nlbit to convert reduction tree value to level and priority. compare level value to mcliccfg.mlvl. if it is less than mcliccfg.mlvl, use scliccfg.nlbit to convert reduction tree value to level and priority. compare level value to scliccfg.slvl.
now that the priv mode is known, if the priv mode > the current priv mode, then take interrupt, else: if mode of winner of priority reduction tree equals current priv mode, compare calculated level with xintthresh and xintstatus of current priv mode.
Since level and priority can be different between different priv modes, does this also make it more difficult to determine valid clicintctl values fw can program in lower priv modes?