Interrupt ID ordering recommendations

[divan0v]

Clarify, please, interrupt ID ordering recommendations.

It seems to me that lines after table in chapter 15 (CLIC Interrupt ID ordering recommendations) contradict with line:
"Original recommendation: The original basic mode interrupts retain their interrupt ID in CLIC mode."

Thanks

[ilg-ul]

Please note that, when using vectored interrupts, in order to avoid unnecessary complexity in a scheduler, it is recommended to reserve the absolute lowest priority interrupt for context switching.

This allows all other handlers to no longer need to deal with saving/restoring registers, but simply pend the context switching interrupt, which will be tail chained when all other nested higher priority interrupts are completed.

Right now the list in chapter 15 starts with User/Supervisor/Machine software Interrupt, but I could not find an explicit mention of which interrupt to use for context switching.

Perhaps this detail should be added to the specs too.

[kasanovic]

The csip interrupt was meant for the background thread, and is allocated such as to have the lowest fixed priority (so an interrupt level does not need to be expended on making it the background thread). The CLINT M/S/U interrupt signals can be added (in parallel) as CLIC inputs in CLIC mode, and then prioritized using CLIC facilities.
The exact numbering for local interrupts across all interrupt controllers needs more discussion -there is overlap with other local interrupts including in the AIA.

[dansmathers]

will move recommendation of csip to 16 for now to avoid conflicts with AIA. CSIP stands for context switch interrupt pending. will add this clarification to spec. will try to connect csip to context switching text to chapter 15.

[dansmathers]

closed by pull #260

[divan0v]

It seems to me that this issue is closed too early.

Original question was a request to clarify contradiction between line:
"CLINT mode compatibility recommendation: The CLINT mode interrupts retain their interrupt ID in CLIC mode."
and lines:
"M-mode only or M/U mode interrupt map recommendation: (in M-only or M/U system without N extension) 0:
M-mode software interrupt 1: M-mode timer interrupt 2+: external (including legacy)
M-mode interrupt map in M/S/U system without N extension recommendation: 0: S-mode software interrupt 1:
S-mode timer interrupt 2: M-mode software interrupt 3: M-mode timer interrupt 4+: external (including legacy)
Interrupt map with PLIC recommendation: 0: S-mode software interrupt 1: S-mode timer interrupt 2: S-mode
external (PLIC) interrupt 3: M-mode software interrupt 4: M-mode timer interrupt 5: M-mode external (PLIC) interrupt 6: external"

Because last lines recommend to move interrupt IDs to new places (not matched with table). Or have I misinterpreted?

[dansmathers]

I updated the formatting of the interrupt recommendation tables to make it more obvious that there are 4 different recommendations depending on the profile that might be targeted. different recommendations were developed based on issue #89 "Being that software will need to handle interrupts differently in CLIC mode vs basic mode, why do we need to have the lower 16 CLIC IDs match the basic interrupt controller?"

Does this make more sense? if not, go ahead and reopen this issue. Thanks.

[divan0v]

1. May be rewrite this phrase: "The CLINT mode interrupts retain their interrupt ID in CLIC mode."?
2. Which number has csip in 15.2, 15.3, 15.4?

[dansmathers]

Can you look at the pull? I tried to point out that these are four different incompatible orderings enumerated here to guide common orderings for software compatibility. some implementations will not need csip so it is not included in 15.2, 15,3, 15.4. more information about profiles can be found here: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#profiles-versus-platforms

[divan0v]

Thanks for pull. It seems good for me.
Motivation for 4 tables became clearer for me.
Thanks.

[dansmathers]

Pull #265 merged. additional text clarification added during TG meeting. closing this for now.

[dansmathers]

discussion about if this section should even be in the spec or moved to the appendix. should the recommendations be allowed to conflict with priv spec? also reference #89.

[christian-herber-nxp]

As it is a recommendation, it belongs in the appendix and is non-normative.
I can imagine that the ARC might want it to be normative, but I would wait for that.
Moving it to the appendix is just improving clarity, making it normative is a spec change.