1. I think some of the questions and discussion concerning this proposal have arisen because the proposal is a little too terse. It would be helpful to have more about the specific use cases that the

Shouldn't exceptions during an NMI just jump to the normal exception handler? That seems like the simplest solution, and would be the behaviour if this extension didn't specify something

The problem is that, although RNMI has a separate vector, the RNMI vector can handle both NMI and normal exceptions but the cause information is only updated on NMI. Here's an illustration of my

Could you go into more detail on how nesting NMIs could work? Shouldn't it only be safe to execute MNRET with rnmie clear, because any NMI that came in between setting mnepc and executing MNRET would

RNMI has separate exception vector from regular exceptions. Krste | Oops - I reread that - Paul is correct; nmcause is not modified. The handler has no guaranteed way of handling an exception. | IT

| I would like a clarification on whether this replaces the existing NMI, or are you saying there are two different things, NMI and RNMI? I doubt it, but I wanted to check. Enhances NMI by adding

M-mode or HS-mode can always create equivalent for S-mode. I don't believe hardware delegation makes sense for NMIs. Krste | I'd expect that S-mode software will also want to be able to receive

| I'll jump in with a few more. :) | From an architectural point of view, I don't like the fact that an NMI blocks further NMI until it leaves its handler. There may be NMIs that can save | the state

| Even though this is hot off the press, I'll jump in with a few small comments: | - In mnstatus, shouldn't there also be a bit like the mstatus.MPV bit (for when the H extension is implemented and

Oops - I reread that - Paul is correct; nmcause is not modified. The handler has no guaranteed way of handling an exception. IT can leave breadcrumbs, but can't guarantee they will be correct

I am assuming here that NMI is an interrupt, not an exception. Both trap, but an mmie-bit only affects interrupts, not exceptions. So, on entry, the handler knows if this was caused by an NMI or by an

"If the hart encounters an exception while the `rnmie` bit is clear, theexception state is written to `mepc` and `mcause`, `mstatus.mpp` is set to M-mode, and the hart jumps to the RNMI exception

I would like a clarification on whether this replaces the existing NMI, or are you saying there are two different things, NMI and RNMI? I doubt it, but I wanted to check. I am concerned that the

I'd expect that S-mode software will also want to be able to receive RNMIs, so it is probably worth thinking through how that would work at the same time. Jonathan

I'll jump in with a few more. :) From an architectural point of view, I don't like the fact that an NMI blocks further NMI until it leaves its handler. There may be NMIs that can save the state they

Even though this is hot off the press, I'll jump in with a few small comments: - In mnstatus, shouldn't there also be a bit like the mstatus.MPV bit (for when the H extension is implemented and

Current RISC-V specs only have a non-resumable NMI definition. The following proposal would add resumable NMI support. This was one of the features requested for priv 1.12 or RVA/RVM22. This is up

When an exception or an ECALL arrives at its handler, the privilege of the code running before the exception/ECALL is always available in MPP or SPP. Bill

This is in the priv spec sec 3.1.6.1 - just search for mret. My explanation of why MPP reverts to Umode is to prevent privilege escalation if you go off the end of the 1-deep privilege level

privilege transitions from levels other than U to a handler at levels other than M are certainly possible. *DELEG,*IE amd *EXCEPT will enable exception handler entry to non-M privilege moss