tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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

By Jonathan Behrens <behrensj@...> · #434 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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

By Krste Asanovic · #433 ·

Re: Resumable NMI proposal

| 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

By Krste Asanovic · #432 ·

Re: Resumable NMI proposal

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

By Krste Asanovic · #431 ·

Re: Resumable NMI proposal

| 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

By Krste Asanovic · #430 ·

Re: Resumable NMI proposal

| 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

By Krste Asanovic · #429 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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

By Allen Baum · #428 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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

By Allen Baum · #427 ·

Re: Resumable NMI proposal

"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

By Paul Donahue · #426 ·

Re: Resumable NMI proposal

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

By Earl Killian · #425 ·

Re: Resumable NMI proposal

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

By Jonathan Behrens <behrensj@...> · #424 ·

Re: Resumable NMI proposal

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

By Brian Grayson · #423 ·

Re: Resumable NMI proposal

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

By Greg Favor · #422 ·

Resumable NMI proposal

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

By Krste Asanovic · #421 ·

Re: MPIE and MPP update when returning from interrupt with MRET

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

By Bill Huffman · #420 ·

Re: MPIE and MPP update when returning from interrupt with MRET

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

By Allen Baum · #419 ·

Re: MPIE and MPP update when returning from interrupt with MRET

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

By Richard Trauben · #418 ·

MPIE and MPP update when returning from interrupt with MRET

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

By Anne MERLANDE · #417 ·

ePMP update

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

By Joe Xie · #416 ·

Re: [EXTERNAL]Re: [RISC-V] [tech-privileged] Performance Monitor Interrupts

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

By Greg Favor · #415 ·

901 - 920 of 1334

Home Hashtags Subgroups Terms