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

Hello The privileged architecture says that when returning from interrupt with MRET, MPIE is set to 1 (and MPP is set to U). What is the rational behind ? Is it still in the context of supporting

Hi TEE group, I would like to give a quick update on ePMP spec. Public review We are still waiting for unpriv group to approve new CSR address assignment. It’s been pending for a while because

Yes. It's not fully in my control, but I'm hoping within the next week or two. Greg

(+platforms, which Mark had added in.) Thanks for the quick reply Greg. Good to know it is of concern to others.😊 I assume the specification will be posted for public review in the