search

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
245 stars 49 forks source link

spec refers to hardware vector table as a load #275

Closed dansmathers closed 2 years ago

dansmathers commented 2 years ago

Apologies if I am missing something, but it is unclear to me how you return to the interrupted context when a fault occurs accessing the vector table based off xtvt.

The spec says "If there is an access exception on the table fetch, xepc is written with the faulting address", but that would immediately overwrite the PC of the interrupted context before there has been any opportunity to save it.

I also noticed that spec is consistent in referring to the vector table access as a fetch (for the purposes of permission checking etc) rather than a load, apart from:

"The inhv bit when set at xRET informs hardware to repeat the table load using the address in xEPC to obtain the address of the trap handler that is then written to the PC instead of directly writing xEPC to the PC. ........ The more privileged layer does not have to distinguish CLIC vector table reads from other forms of data page fault and can handle them using exactly the same code."

Any clarification on these two points would be helpful.

dansmathers commented 2 years ago

that's correct that if the access exception on the table fetch is the same priv as the interrupt handler, that xepc is lost. that's what the spec means when it says: Horizontal traps (same privilege level) are unrecoverable. But we should probably clarify that statement since systems can figure out ways to recover but we just mean that the interrupted context is lost.

MarkHillHuawei commented 2 years ago

But I think both vertical and horizontal interrupted contexts are corrupted as the PC of the interrupted context would always be stored in xepc (with its privilege level in xpp), the value of xepc would then be immediately over-written with the faulting vector table entry address.

dansmathers commented 2 years ago

vertical should be ok.
When a trap is taken into S-mode, sepc is written with the virtual address of the instruction that was interrupted if there is an access exception into m-mode due to the table fetch: When a trap is taken into M-mode, mepc is written with the virtual address of the instruction that encountered the exception. so in vertical interrupt contexts, it is a different epc.

but I guess you may have understood vertical to just mean the u-mode code is interrupted to m-mode handler as being the vertical interrupt context? The clic spec intends vertical to mean the interrupt handler and the exception handler are vertical.

MarkHillHuawei commented 2 years ago

I think the bottom line is that the mechanism does not support delivery of interrupts into m-mode. In particular, in a U/M system (assuming no N extension) it is not a recoverable situation so perhaps the scheme should be omitted altogether from those profiles.

kasanovic commented 2 years ago

Closed with https://github.com/riscv/riscv-fast-interrupt/commit/edc9d203ad3956d54e85221448b7bb5e28f34eaa