riscv / riscv-fast-interrupt

Proposal for a RISC-V Core-Local Interrupt Controller (CLIC)
https://jira.riscv.org/browse/RVG-63
Creative Commons Attribution 4.0 International
248 stars 49 forks source link

xcause.xpil and xpie behavior on trap taken and xRET #339

Closed hwliu-tommy closed 1 year ago

hwliu-tommy commented 1 year ago

Hi,

I have 2 questions about the descriptions of xpil and xpie in section 4.7.6 and 4.10.1.

  1. xpil, the spec says:

    If the hart is currently running at some privilege mode (pp) at some interrupt level (pil) and an enabled interrupt becomes pending ... The CSR xepc is set to the PC of the interrupted application code or preempted interrupt handler, while the xcause register now captures the previous privilege mode (pp), interrupt level (pil) and interrupt enable (pie) ...(section 4.7.6)

The regular xret instructions are used to return from handlers in privilege mode x. Execution continues at the saved privilege mode xcause.xpp, at PC xepc, with interrupt level xcause.xpil ... (section 4.10.1)

My interpretation is that when a M-mode interrupt is taken from S-mode, sil should be saved to mpil. And when MRET changes the privilege to S-mode, sil should be updated to mpil. Is this interpretation correct? Because the xie behavior in this case will be: on trap taken: mpie <- mie <- 0 on MRET: mie <- mpie

  1. xpie

    The regular xret instructions are used to return from handlers in privilege mode x. Execution continues at the saved privilege mode xcause.xpp, at PC xepc, with interrupt level xcause.xpil, and with the global interrupt enable for the restored mode as xcause.xpie. (section 4.10.1)

I have a suggestion that maybe we could define these behaviors as the xIE, xRET descriptions in privileged spec? For example: when a trap is taken from privilege mode y into privilege mode x, xPP = y. User can simply replace x, y with the corresponding privileges, I think it would be easier to understand the behavior.

Thanks, Tommy

kasanovic commented 1 year ago

Closed with https://github.com/riscv/riscv-fast-interrupt/pull/340

dansmathers commented 1 year ago

This text was added to the clic spec in pull #340:

As stated in the RISC-V privilege specification, when a trap is taken from privilege mode y into privilege mode x, xPIE is set to the value of x IE; xIE is set to 0; and xPP is set to y. xepc is written with the virtual address of the instruction that was interrupted or that encountered the exception.
Additionally in CLIC mode, interrupt level (xpil) is set to xstatus.xil and xcause.exccode is written with a code indicating the event (the id of the interrupt or exception code) that caused the trap.

Do we actually want mcause.mpil to be updated on exceptions (non-interrupts)? what if there is a breakpoint in an interrupt handler. after the breakpoint resumes, mcause.mpil would be wrong and need to be updated before resuming the breakpoint? Let's discuss in our TG meeting

kasanovic commented 1 year ago

Fix xstatus -> xintstatus

Text already covers exception case in section 4.9.4 "Synchronous Exception Handling". Debug mode is considered a more privileged mode than M, so breakpoint into debug mode is a vertical trap.

dansmathers commented 1 year ago

xstatus.xil to xintstatus.xil typo fixed. https://github.com/riscv/riscv-fast-interrupt/commit/79c6f119f2837cafeefa4e25751615815e5668f3

closing issue.