Date   

Re: Resumable NMI proposal

Krste Asanovic
 

On Tue, 19 Jan 2021 10:36:26 -0600, Brian Grayson <brian.grayson@...> said:
| 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 need, and then unblock further NMIs, i.e., they might be stackable in some cases. This spec precludes that by making rnmie not
| software-writable.

| I also fundamentally dislike the use of the term "non-maskable", because the proposed rnmie bit literally masks non-maskable interrupts. That's an
| impossible thing to put into a spec, as remarked upon in your NOTE.

rnmie should be settable but not clearable in M-mode to support
nesting NMIs.

(This was an editing error on my part, as I simplified earlier spec
but didn't include this mod.)

This still makes them non-maskable by software; NMI is
industry-standard term.

| From a prior art point of view, the PowerPC Book E architecture (the embedded flavor) handled this differently. It called NMIs "critical interrupts",
| and all critical interrupts are higher priority than non-critical. They can be masked, and further critical interrupts are automatically masked when a
| critical interrupt is taken, but software in the critical interrupt handler can save the state it needs, and then re-enable further critical interrupts
| if that is desired. I believe this is ultimately the desired behavior for us as well, and is IMO better architectural terminology and a better mental
| framework.

Fast interrupts proposal has pre-emptible levels intended for embedded
systems.

I think these are qualitatively different than NMI, which are needed
in application processors too.

| Within non-critical interrupts, some debug events were considered highest priority, some were considered lowest priority, depending on the type of debug
| event. It can be difficult (or even impossible) to assert that all debug events are all higher or all lower than a given exception event.

| See Chapter 7 "Interrupts and Exceptions" of https://www.nxp.com/docs/en/user-guide/BOOK_EUM.pdf for more details, and in particular 7.9.1 that talks
| about the relative priority of all the different types of interrupts in both classes, and where various debug interrupts fell.

| Back to the proposal, I think there's a mistake near the end:

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

| If the enable bit is clear, the exception can't be taken, right? Is this supposed to discuss the case of an ordinary exception being observed while in
| RNMI, where the exception will actually be instantly taken once we leave RNMI state, in which case we would jump to the ordinary exception handler? Or
| am I misunderstanding?

Exceptions are not interrupts. NMI exceptions go to different vector address
than regular exceptions,

Krste

| Brian

| On Mon, Jan 18, 2021 at 9:09 PM Greg Favor <gfavor@...> wrote:

| 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 enabled)?

| - The width of the mnstatus CSR is not explicitly defined (e.g. as an XLEN-bit or 32-bit read-write register).

| - What is the relative priority for RNMI versus Debug Halt Request?  Maybe it is the responsibility ultimately for the Debug spec to specify this
| (?), but what should be said over there?

| - Can you briefly comment on the types of systems that show the most need for recoverable NMIs (versus being not ideal but ok with the current NMI
| situation).  Semi-equivalently, would you expect this extension to eventually become a requirement (or optional) in RVA22 and/or RVM22?

| Greg

| On Mon, Jan 18, 2021 at 6:39 PM Krste Asanovic <krste@...> wrote:

| 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 for discussion, but I think it is small enough to go
| through fast track process.

| Krste

| :sectnums:
| :toc: left

| = Resumable NMI support in RISC-V
| Version 0.2.1-Draft

| == Background and Motivation

| The RISC-V privileged architecture version 1.11 supports only
| unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
| handler in machine mode, overwriting the current `mepc` and `mcause`
| register values.  If the hart had been executing machine-mode code in
| a trap handler, the previous values in `mepc` and `mcause` would not
| be recoverable and so execution is not generally resumable.

| This proposal adds support for resumable non-maskable interrupts
| (RNMIs) to RISC-V.  The extension adds four new CSRs (`mnepc`,
| `mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
| and a new instruction to resume from the RNMI handler.

| == RNMI Interrupt Signals

| The `rnmi` interrupt signals are inputs to
| the hart.  These interrupts have higher priority than any other
| interrupt or exception on the hart and cannot be disabled by software.
| Specifically, they are not disabled by clearing the `mstatus.mie`
| register.

| == RNMI Handler Addresses

| The RNMI interrupt trap handler address is implementation-defined.

| RNMI also has an associated exception trap handler address, which is
| implementation defined.

| == New RNMI CSRs

| This proposal adds additional M-mode CSRs to enable a resumable
| non-maskable interrupt (RNMI).

| .NMI additional CSRs
| [cols="2,2,2,2"]
| [%autowidth]
| |===
| | Number | Privilege | Name        | Description

| | 0x350  | MRW       | `mnscratch` | Resumable Non-maskable scratch register
| | 0x351  | MRW       | `mnepc`     | Resumable Non-maskable EPC value
| | 0x352  | MRW       | `mncause`   | Resumable Non-maskable cause value
| | 0x353  | MRW       | `mnstatus`  | Resumable Non-maskable status
| |===

| The `mnscratch` CSR holds an XLEN-bit read-write register which
| enables the NMI trap handler to save and restore the context that was
| interrupted.

| The `mnepc` CSR is an XLEN-bit read-write register which on entry
| to the NMI trap handler holds the PC of the instruction that took the
| interrupt. The lowest bit of `mnepc` is hardwired to zero.

| The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
| 1, and the NMI cause encoded in the least-significant bits or zero if
| NMI causes are not supported.

| The `mnstatus` CSR holds a two-bit field which on entry to the trap
| handler holds the privilege mode of the interrupted context encoded in
| bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`.  The other
| bits in `mnstatus` are _reserved_, but software should write zeros and
| hardware implementations should return zeros.

| == New MNRET instruction

| This new M-mode only instruction uses the values in `mnepc` and
| `mnstatus` to return to the program counter and privileged mode of the
| interrupted context respectively.  This instruction also sets the
| `rnmie` state bit.

| MNRET instruction encoding is same as MRET except with bit 30 set
| (i.e.,`funct7`=`0111000`).

| == RNMI Operation

| When an RNMI interrupt is detected, the interrupted PC is written to
| the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
| privilege mode of the interrupted context to the `mnstatus` CSR.  An
| internal microarchitectural state bit `rnmie` is cleared to indicate
| that processor is in an RNMI handler and cannot take a new RNMI
| interrupt.  The internal `rnmie` bit when clear also disables all
| other interrupts.

| NOTE: These interrupts are called non-maskable because software cannot
| mask the interrupts, but for correct operation other instances of the
| same interrupt must be held off until the handler is completed, hence
| the internal state bit.

| The core then enters machine-mode and jumps to the RNMI trap handler
| address.

| The RNMI handler can resume original execution using the new MNRET
| instruction, which restores the PC from `mnepc`, the privilege mode
| from `mnstatus`, and also sets the internal `rnmie` state bit, which
| reenables other interrupts.

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

| NOTE: Traps in the RNMI handler can only be resumed if they occur while
| the handler was servicing an interrupt that occured outside of
| machine-mode.

| == Interaction with debugger

| The debugger can be configured such that an RNMI event drops the
| system into the debugger.

|


Re: Resumable NMI proposal

Krste Asanovic
 

On Mon, 18 Jan 2021 19:09:26 -0800, Greg Favor <gfavor@...> said:
| 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 enabled)?

I'll let hypervisor authors address this.

| - The width of the mnstatus CSR is not explicitly defined (e.g. as an XLEN-bit or 32-bit read-write register).
Should be XLEN to match mstatus.

| - What is the relative priority for RNMI versus Debug Halt Request?  Maybe it is the responsibility ultimately for the Debug spec to specify this (?),
| but what should be said over there?
I'll let debug group figure this out.

| - Can you briefly comment on the types of systems that show the most need for recoverable NMIs (versus being not ideal but ok with the current NMI
| situation).  Semi-equivalently, would you expect this extension to eventually become a requirement (or optional) in RVA22 and/or RVM22?

Where external agent outside OS stack has to respond to the interrupt
and resume OS, e.g, hardware error logging/reporting inc watchdogs, or
some forms of power down.

Yes for RVA22/RVM22, and I would think mandatory in RVA22, optional in
RVM22.

Platform specs would have to indicate what/how NMIs are
generated/routed.

Krste

| Greg

| On Mon, Jan 18, 2021 at 6:39 PM Krste Asanovic <krste@...> wrote:

| 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 for discussion, but I think it is small enough to go
| through fast track process.

| Krste

| :sectnums:
| :toc: left

| = Resumable NMI support in RISC-V
| Version 0.2.1-Draft

| == Background and Motivation

| The RISC-V privileged architecture version 1.11 supports only
| unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
| handler in machine mode, overwriting the current `mepc` and `mcause`
| register values.  If the hart had been executing machine-mode code in
| a trap handler, the previous values in `mepc` and `mcause` would not
| be recoverable and so execution is not generally resumable.

| This proposal adds support for resumable non-maskable interrupts
| (RNMIs) to RISC-V.  The extension adds four new CSRs (`mnepc`,
| `mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
| and a new instruction to resume from the RNMI handler.

| == RNMI Interrupt Signals

| The `rnmi` interrupt signals are inputs to
| the hart.  These interrupts have higher priority than any other
| interrupt or exception on the hart and cannot be disabled by software.
| Specifically, they are not disabled by clearing the `mstatus.mie`
| register.

| == RNMI Handler Addresses

| The RNMI interrupt trap handler address is implementation-defined.

| RNMI also has an associated exception trap handler address, which is
| implementation defined.

| == New RNMI CSRs

| This proposal adds additional M-mode CSRs to enable a resumable
| non-maskable interrupt (RNMI).

| .NMI additional CSRs
| [cols="2,2,2,2"]
| [%autowidth]
| |===
| | Number | Privilege | Name        | Description

| | 0x350  | MRW       | `mnscratch` | Resumable Non-maskable scratch register
| | 0x351  | MRW       | `mnepc`     | Resumable Non-maskable EPC value
| | 0x352  | MRW       | `mncause`   | Resumable Non-maskable cause value
| | 0x353  | MRW       | `mnstatus`  | Resumable Non-maskable status
| |===

| The `mnscratch` CSR holds an XLEN-bit read-write register which
| enables the NMI trap handler to save and restore the context that was
| interrupted.

| The `mnepc` CSR is an XLEN-bit read-write register which on entry
| to the NMI trap handler holds the PC of the instruction that took the
| interrupt. The lowest bit of `mnepc` is hardwired to zero.

| The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
| 1, and the NMI cause encoded in the least-significant bits or zero if
| NMI causes are not supported.

| The `mnstatus` CSR holds a two-bit field which on entry to the trap
| handler holds the privilege mode of the interrupted context encoded in
| bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`.  The other
| bits in `mnstatus` are _reserved_, but software should write zeros and
| hardware implementations should return zeros.

| == New MNRET instruction

| This new M-mode only instruction uses the values in `mnepc` and
| `mnstatus` to return to the program counter and privileged mode of the
| interrupted context respectively.  This instruction also sets the
| `rnmie` state bit.

| MNRET instruction encoding is same as MRET except with bit 30 set
| (i.e.,`funct7`=`0111000`).

| == RNMI Operation

| When an RNMI interrupt is detected, the interrupted PC is written to
| the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
| privilege mode of the interrupted context to the `mnstatus` CSR.  An
| internal microarchitectural state bit `rnmie` is cleared to indicate
| that processor is in an RNMI handler and cannot take a new RNMI
| interrupt.  The internal `rnmie` bit when clear also disables all
| other interrupts.

| NOTE: These interrupts are called non-maskable because software cannot
| mask the interrupts, but for correct operation other instances of the
| same interrupt must be held off until the handler is completed, hence
| the internal state bit.

| The core then enters machine-mode and jumps to the RNMI trap handler
| address.

| The RNMI handler can resume original execution using the new MNRET
| instruction, which restores the PC from `mnepc`, the privilege mode
| from `mnstatus`, and also sets the internal `rnmie` state bit, which
| reenables other interrupts.

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

| NOTE: Traps in the RNMI handler can only be resumed if they occur while
| the handler was servicing an interrupt that occured outside of
| machine-mode.

| == Interaction with debugger

| The debugger can be configured such that an RNMI event drops the
| system into the debugger.

|


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

Allen Baum
 

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 depending on when an exception cocurrs.

On Tue, Jan 19, 2021 at 5:46 PM Allen Baum <allen.baum@...> wrote:
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 exception from the rnmi handler itself by looking at the MSB of nmcause.

I am also assuming that:
RNMI interrupts are not delegated
Accesses made in the RNMI handler are made just as if the hart were in Mmode, so it has to save and restore MPRV if it wants to use it.

I'm not exactly sure why MNRET is needed at all - it can use the hidden MMIE bit to select returning to mepc or nmepc, and restoring the priv level from nmstatus.pp rather than mstatus.pp, and inhibit popping the pp and ie stacks.
And what happens if you execute mret or sret in the rnmi handler (when mmie=0)? That doesn't sound good..

On Tue, Jan 19, 2021 at 2:52 PM Paul Donahue <pdonahue@...> wrote:
"If the hart encounters an exception while the `rnmie` bit is clear, the
exception state is written to `mepc` and `mcause`, `mstatus.mpp` is
set to M-mode, and the hart jumps to the RNMI exception handler
address."

How does the RNMI handler distinguish between entry due to an NMI and entry due to an exception while rnmie=0?  It needs this information to decide whether the cause is in mcause or mncause.

On an exception when rnmie=0, is there a reason that mstatus.mpp is always set to M mode even if the exception occurred in some other mode?

Is medeleg ignored on traps when rnmie=0?  The handler address is specified but the handler mode is not.  Since the handler address is an M-mode address (not subject to translation), I assume that the handler mode is always M and that medeleg must be ignored.


Thanks,

-Paul


On Tue, Jan 19, 2021 at 10:04 AM Earl Killian <earl.killian@...> wrote:
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 rnmie is hidden and only settable by MNRET. This means that to re-enable NMI for a portion of a NMI handler (e.g. after saving all the appropriate information to a NMI stack) one must write mnepc and then MNRET there, but there is no way to disable it for the real MNRET.

> On Jan 18, 2021, at 18:39, Krste Asanovic <krste@...> wrote:
>
>
> 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 for discussion, but I think it is small enough to go
> through fast track process.
>
> Krste
>
> :sectnums:
> :toc: left
>
> = Resumable NMI support in RISC-V
> Version 0.2.1-Draft
>
> == Background and Motivation
>
> The RISC-V privileged architecture version 1.11 supports only
> unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
> handler in machine mode, overwriting the current `mepc` and `mcause`
> register values.  If the hart had been executing machine-mode code in
> a trap handler, the previous values in `mepc` and `mcause` would not
> be recoverable and so execution is not generally resumable.
>
> This proposal adds support for resumable non-maskable interrupts
> (RNMIs) to RISC-V.  The extension adds four new CSRs (`mnepc`,
> `mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
> and a new instruction to resume from the RNMI handler.
>
> == RNMI Interrupt Signals
>
> The `rnmi` interrupt signals are inputs to
> the hart.  These interrupts have higher priority than any other
> interrupt or exception on the hart and cannot be disabled by software.
> Specifically, they are not disabled by clearing the `mstatus.mie`
> register.
>
> == RNMI Handler Addresses
>
> The RNMI interrupt trap handler address is implementation-defined.
>
> RNMI also has an associated exception trap handler address, which is
> implementation defined.
>
> == New RNMI CSRs
>
> This proposal adds additional M-mode CSRs to enable a resumable
> non-maskable interrupt (RNMI).
>
> .NMI additional CSRs
> [cols="2,2,2,2"]
> [%autowidth]
> |===
> | Number | Privilege | Name        | Description
>
> | 0x350  | MRW       | `mnscratch` | Resumable Non-maskable scratch register
> | 0x351  | MRW       | `mnepc`     | Resumable Non-maskable EPC value
> | 0x352  | MRW       | `mncause`   | Resumable Non-maskable cause value
> | 0x353  | MRW       | `mnstatus`  | Resumable Non-maskable status
> |===
>
> The `mnscratch` CSR holds an XLEN-bit read-write register which
> enables the NMI trap handler to save and restore the context that was
> interrupted.
>
> The `mnepc` CSR is an XLEN-bit read-write register which on entry
> to the NMI trap handler holds the PC of the instruction that took the
> interrupt. The lowest bit of `mnepc` is hardwired to zero.
>
> The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
> 1, and the NMI cause encoded in the least-significant bits or zero if
> NMI causes are not supported.
>
> The `mnstatus` CSR holds a two-bit field which on entry to the trap
> handler holds the privilege mode of the interrupted context encoded in
> bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`.  The other
> bits in `mnstatus` are _reserved_, but software should write zeros and
> hardware implementations should return zeros.
>
> == New MNRET instruction
>
> This new M-mode only instruction uses the values in `mnepc` and
> `mnstatus` to return to the program counter and privileged mode of the
> interrupted context respectively.  This instruction also sets the
> `rnmie` state bit.
>
> MNRET instruction encoding is same as MRET except with bit 30 set
> (i.e.,`funct7`=`0111000`).
>
> == RNMI Operation
>
> When an RNMI interrupt is detected, the interrupted PC is written to
> the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
> privilege mode of the interrupted context to the `mnstatus` CSR.  An
> internal microarchitectural state bit `rnmie` is cleared to indicate
> that processor is in an RNMI handler and cannot take a new RNMI
> interrupt.  The internal `rnmie` bit when clear also disables all
> other interrupts.
>
> NOTE: These interrupts are called non-maskable because software cannot
> mask the interrupts, but for correct operation other instances of the
> same interrupt must be held off until the handler is completed, hence
> the internal state bit.
>
> The core then enters machine-mode and jumps to the RNMI trap handler
> address.
>
> The RNMI handler can resume original execution using the new MNRET
> instruction, which restores the PC from `mnepc`, the privilege mode
> from `mnstatus`, and also sets the internal `rnmie` state bit, which
> reenables other interrupts.
>
> If the hart encounters an exception while the `rnmie` bit is clear, the
> exception state is written to `mepc` and `mcause`, `mstatus.mpp` is
> set to M-mode, and the hart jumps to the RNMI exception handler
> address.
>
> NOTE: Traps in the RNMI handler can only be resumed if they occur while
> the handler was servicing an interrupt that occured outside of
> machine-mode.
>
> == Interaction with debugger
>
> The debugger can be configured such that an RNMI event drops the
> system into the debugger.
>
>
>
>
>







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

Allen Baum
 

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 exception from the rnmi handler itself by looking at the MSB of nmcause.

I am also assuming that:
RNMI interrupts are not delegated
Accesses made in the RNMI handler are made just as if the hart were in Mmode, so it has to save and restore MPRV if it wants to use it.

I'm not exactly sure why MNRET is needed at all - it can use the hidden MMIE bit to select returning to mepc or nmepc, and restoring the priv level from nmstatus.pp rather than mstatus.pp, and inhibit popping the pp and ie stacks.
And what happens if you execute mret or sret in the rnmi handler (when mmie=0)? That doesn't sound good..


On Tue, Jan 19, 2021 at 2:52 PM Paul Donahue <pdonahue@...> wrote:
"If the hart encounters an exception while the `rnmie` bit is clear, the
exception state is written to `mepc` and `mcause`, `mstatus.mpp` is
set to M-mode, and the hart jumps to the RNMI exception handler
address."

How does the RNMI handler distinguish between entry due to an NMI and entry due to an exception while rnmie=0?  It needs this information to decide whether the cause is in mcause or mncause.

On an exception when rnmie=0, is there a reason that mstatus.mpp is always set to M mode even if the exception occurred in some other mode?

Is medeleg ignored on traps when rnmie=0?  The handler address is specified but the handler mode is not.  Since the handler address is an M-mode address (not subject to translation), I assume that the handler mode is always M and that medeleg must be ignored.


Thanks,

-Paul


On Tue, Jan 19, 2021 at 10:04 AM Earl Killian <earl.killian@...> wrote:
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 rnmie is hidden and only settable by MNRET. This means that to re-enable NMI for a portion of a NMI handler (e.g. after saving all the appropriate information to a NMI stack) one must write mnepc and then MNRET there, but there is no way to disable it for the real MNRET.

> On Jan 18, 2021, at 18:39, Krste Asanovic <krste@...> wrote:
>
>
> 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 for discussion, but I think it is small enough to go
> through fast track process.
>
> Krste
>
> :sectnums:
> :toc: left
>
> = Resumable NMI support in RISC-V
> Version 0.2.1-Draft
>
> == Background and Motivation
>
> The RISC-V privileged architecture version 1.11 supports only
> unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
> handler in machine mode, overwriting the current `mepc` and `mcause`
> register values.  If the hart had been executing machine-mode code in
> a trap handler, the previous values in `mepc` and `mcause` would not
> be recoverable and so execution is not generally resumable.
>
> This proposal adds support for resumable non-maskable interrupts
> (RNMIs) to RISC-V.  The extension adds four new CSRs (`mnepc`,
> `mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
> and a new instruction to resume from the RNMI handler.
>
> == RNMI Interrupt Signals
>
> The `rnmi` interrupt signals are inputs to
> the hart.  These interrupts have higher priority than any other
> interrupt or exception on the hart and cannot be disabled by software.
> Specifically, they are not disabled by clearing the `mstatus.mie`
> register.
>
> == RNMI Handler Addresses
>
> The RNMI interrupt trap handler address is implementation-defined.
>
> RNMI also has an associated exception trap handler address, which is
> implementation defined.
>
> == New RNMI CSRs
>
> This proposal adds additional M-mode CSRs to enable a resumable
> non-maskable interrupt (RNMI).
>
> .NMI additional CSRs
> [cols="2,2,2,2"]
> [%autowidth]
> |===
> | Number | Privilege | Name        | Description
>
> | 0x350  | MRW       | `mnscratch` | Resumable Non-maskable scratch register
> | 0x351  | MRW       | `mnepc`     | Resumable Non-maskable EPC value
> | 0x352  | MRW       | `mncause`   | Resumable Non-maskable cause value
> | 0x353  | MRW       | `mnstatus`  | Resumable Non-maskable status
> |===
>
> The `mnscratch` CSR holds an XLEN-bit read-write register which
> enables the NMI trap handler to save and restore the context that was
> interrupted.
>
> The `mnepc` CSR is an XLEN-bit read-write register which on entry
> to the NMI trap handler holds the PC of the instruction that took the
> interrupt. The lowest bit of `mnepc` is hardwired to zero.
>
> The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
> 1, and the NMI cause encoded in the least-significant bits or zero if
> NMI causes are not supported.
>
> The `mnstatus` CSR holds a two-bit field which on entry to the trap
> handler holds the privilege mode of the interrupted context encoded in
> bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`.  The other
> bits in `mnstatus` are _reserved_, but software should write zeros and
> hardware implementations should return zeros.
>
> == New MNRET instruction
>
> This new M-mode only instruction uses the values in `mnepc` and
> `mnstatus` to return to the program counter and privileged mode of the
> interrupted context respectively.  This instruction also sets the
> `rnmie` state bit.
>
> MNRET instruction encoding is same as MRET except with bit 30 set
> (i.e.,`funct7`=`0111000`).
>
> == RNMI Operation
>
> When an RNMI interrupt is detected, the interrupted PC is written to
> the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
> privilege mode of the interrupted context to the `mnstatus` CSR.  An
> internal microarchitectural state bit `rnmie` is cleared to indicate
> that processor is in an RNMI handler and cannot take a new RNMI
> interrupt.  The internal `rnmie` bit when clear also disables all
> other interrupts.
>
> NOTE: These interrupts are called non-maskable because software cannot
> mask the interrupts, but for correct operation other instances of the
> same interrupt must be held off until the handler is completed, hence
> the internal state bit.
>
> The core then enters machine-mode and jumps to the RNMI trap handler
> address.
>
> The RNMI handler can resume original execution using the new MNRET
> instruction, which restores the PC from `mnepc`, the privilege mode
> from `mnstatus`, and also sets the internal `rnmie` state bit, which
> reenables other interrupts.
>
> If the hart encounters an exception while the `rnmie` bit is clear, the
> exception state is written to `mepc` and `mcause`, `mstatus.mpp` is
> set to M-mode, and the hart jumps to the RNMI exception handler
> address.
>
> NOTE: Traps in the RNMI handler can only be resumed if they occur while
> the handler was servicing an interrupt that occured outside of
> machine-mode.
>
> == Interaction with debugger
>
> The debugger can be configured such that an RNMI event drops the
> system into the debugger.
>
>
>
>
>







Re: Resumable NMI proposal

Paul Donahue
 

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

How does the RNMI handler distinguish between entry due to an NMI and entry due to an exception while rnmie=0?  It needs this information to decide whether the cause is in mcause or mncause.

On an exception when rnmie=0, is there a reason that mstatus.mpp is always set to M mode even if the exception occurred in some other mode?

Is medeleg ignored on traps when rnmie=0?  The handler address is specified but the handler mode is not.  Since the handler address is an M-mode address (not subject to translation), I assume that the handler mode is always M and that medeleg must be ignored.


Thanks,

-Paul


On Tue, Jan 19, 2021 at 10:04 AM Earl Killian <earl.killian@...> wrote:
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 rnmie is hidden and only settable by MNRET. This means that to re-enable NMI for a portion of a NMI handler (e.g. after saving all the appropriate information to a NMI stack) one must write mnepc and then MNRET there, but there is no way to disable it for the real MNRET.

> On Jan 18, 2021, at 18:39, Krste Asanovic <krste@...> wrote:
>
>
> 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 for discussion, but I think it is small enough to go
> through fast track process.
>
> Krste
>
> :sectnums:
> :toc: left
>
> = Resumable NMI support in RISC-V
> Version 0.2.1-Draft
>
> == Background and Motivation
>
> The RISC-V privileged architecture version 1.11 supports only
> unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
> handler in machine mode, overwriting the current `mepc` and `mcause`
> register values.  If the hart had been executing machine-mode code in
> a trap handler, the previous values in `mepc` and `mcause` would not
> be recoverable and so execution is not generally resumable.
>
> This proposal adds support for resumable non-maskable interrupts
> (RNMIs) to RISC-V.  The extension adds four new CSRs (`mnepc`,
> `mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
> and a new instruction to resume from the RNMI handler.
>
> == RNMI Interrupt Signals
>
> The `rnmi` interrupt signals are inputs to
> the hart.  These interrupts have higher priority than any other
> interrupt or exception on the hart and cannot be disabled by software.
> Specifically, they are not disabled by clearing the `mstatus.mie`
> register.
>
> == RNMI Handler Addresses
>
> The RNMI interrupt trap handler address is implementation-defined.
>
> RNMI also has an associated exception trap handler address, which is
> implementation defined.
>
> == New RNMI CSRs
>
> This proposal adds additional M-mode CSRs to enable a resumable
> non-maskable interrupt (RNMI).
>
> .NMI additional CSRs
> [cols="2,2,2,2"]
> [%autowidth]
> |===
> | Number | Privilege | Name        | Description
>
> | 0x350  | MRW       | `mnscratch` | Resumable Non-maskable scratch register
> | 0x351  | MRW       | `mnepc`     | Resumable Non-maskable EPC value
> | 0x352  | MRW       | `mncause`   | Resumable Non-maskable cause value
> | 0x353  | MRW       | `mnstatus`  | Resumable Non-maskable status
> |===
>
> The `mnscratch` CSR holds an XLEN-bit read-write register which
> enables the NMI trap handler to save and restore the context that was
> interrupted.
>
> The `mnepc` CSR is an XLEN-bit read-write register which on entry
> to the NMI trap handler holds the PC of the instruction that took the
> interrupt. The lowest bit of `mnepc` is hardwired to zero.
>
> The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
> 1, and the NMI cause encoded in the least-significant bits or zero if
> NMI causes are not supported.
>
> The `mnstatus` CSR holds a two-bit field which on entry to the trap
> handler holds the privilege mode of the interrupted context encoded in
> bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`.  The other
> bits in `mnstatus` are _reserved_, but software should write zeros and
> hardware implementations should return zeros.
>
> == New MNRET instruction
>
> This new M-mode only instruction uses the values in `mnepc` and
> `mnstatus` to return to the program counter and privileged mode of the
> interrupted context respectively.  This instruction also sets the
> `rnmie` state bit.
>
> MNRET instruction encoding is same as MRET except with bit 30 set
> (i.e.,`funct7`=`0111000`).
>
> == RNMI Operation
>
> When an RNMI interrupt is detected, the interrupted PC is written to
> the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
> privilege mode of the interrupted context to the `mnstatus` CSR.  An
> internal microarchitectural state bit `rnmie` is cleared to indicate
> that processor is in an RNMI handler and cannot take a new RNMI
> interrupt.  The internal `rnmie` bit when clear also disables all
> other interrupts.
>
> NOTE: These interrupts are called non-maskable because software cannot
> mask the interrupts, but for correct operation other instances of the
> same interrupt must be held off until the handler is completed, hence
> the internal state bit.
>
> The core then enters machine-mode and jumps to the RNMI trap handler
> address.
>
> The RNMI handler can resume original execution using the new MNRET
> instruction, which restores the PC from `mnepc`, the privilege mode
> from `mnstatus`, and also sets the internal `rnmie` state bit, which
> reenables other interrupts.
>
> If the hart encounters an exception while the `rnmie` bit is clear, the
> exception state is written to `mepc` and `mcause`, `mstatus.mpp` is
> set to M-mode, and the hart jumps to the RNMI exception handler
> address.
>
> NOTE: Traps in the RNMI handler can only be resumed if they occur while
> the handler was servicing an interrupt that occured outside of
> machine-mode.
>
> == Interaction with debugger
>
> The debugger can be configured such that an RNMI event drops the
> system into the debugger.
>
>
>
>
>







Re: Resumable NMI proposal

Earl Killian
 

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 rnmie is hidden and only settable by MNRET. This means that to re-enable NMI for a portion of a NMI handler (e.g. after saving all the appropriate information to a NMI stack) one must write mnepc and then MNRET there, but there is no way to disable it for the real MNRET.

On Jan 18, 2021, at 18:39, Krste Asanovic <krste@...> wrote:


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 for discussion, but I think it is small enough to go
through fast track process.

Krste

:sectnums:
:toc: left

= Resumable NMI support in RISC-V
Version 0.2.1-Draft

== Background and Motivation

The RISC-V privileged architecture version 1.11 supports only
unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
handler in machine mode, overwriting the current `mepc` and `mcause`
register values. If the hart had been executing machine-mode code in
a trap handler, the previous values in `mepc` and `mcause` would not
be recoverable and so execution is not generally resumable.

This proposal adds support for resumable non-maskable interrupts
(RNMIs) to RISC-V. The extension adds four new CSRs (`mnepc`,
`mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
and a new instruction to resume from the RNMI handler.

== RNMI Interrupt Signals

The `rnmi` interrupt signals are inputs to
the hart. These interrupts have higher priority than any other
interrupt or exception on the hart and cannot be disabled by software.
Specifically, they are not disabled by clearing the `mstatus.mie`
register.

== RNMI Handler Addresses

The RNMI interrupt trap handler address is implementation-defined.

RNMI also has an associated exception trap handler address, which is
implementation defined.

== New RNMI CSRs

This proposal adds additional M-mode CSRs to enable a resumable
non-maskable interrupt (RNMI).

.NMI additional CSRs
[cols="2,2,2,2"]
[%autowidth]
|===
| Number | Privilege | Name | Description

| 0x350 | MRW | `mnscratch` | Resumable Non-maskable scratch register
| 0x351 | MRW | `mnepc` | Resumable Non-maskable EPC value
| 0x352 | MRW | `mncause` | Resumable Non-maskable cause value
| 0x353 | MRW | `mnstatus` | Resumable Non-maskable status
|===

The `mnscratch` CSR holds an XLEN-bit read-write register which
enables the NMI trap handler to save and restore the context that was
interrupted.

The `mnepc` CSR is an XLEN-bit read-write register which on entry
to the NMI trap handler holds the PC of the instruction that took the
interrupt. The lowest bit of `mnepc` is hardwired to zero.

The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
1, and the NMI cause encoded in the least-significant bits or zero if
NMI causes are not supported.

The `mnstatus` CSR holds a two-bit field which on entry to the trap
handler holds the privilege mode of the interrupted context encoded in
bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`. The other
bits in `mnstatus` are _reserved_, but software should write zeros and
hardware implementations should return zeros.

== New MNRET instruction

This new M-mode only instruction uses the values in `mnepc` and
`mnstatus` to return to the program counter and privileged mode of the
interrupted context respectively. This instruction also sets the
`rnmie` state bit.

MNRET instruction encoding is same as MRET except with bit 30 set
(i.e.,`funct7`=`0111000`).

== RNMI Operation

When an RNMI interrupt is detected, the interrupted PC is written to
the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
privilege mode of the interrupted context to the `mnstatus` CSR. An
internal microarchitectural state bit `rnmie` is cleared to indicate
that processor is in an RNMI handler and cannot take a new RNMI
interrupt. The internal `rnmie` bit when clear also disables all
other interrupts.

NOTE: These interrupts are called non-maskable because software cannot
mask the interrupts, but for correct operation other instances of the
same interrupt must be held off until the handler is completed, hence
the internal state bit.

The core then enters machine-mode and jumps to the RNMI trap handler
address.

The RNMI handler can resume original execution using the new MNRET
instruction, which restores the PC from `mnepc`, the privilege mode
from `mnstatus`, and also sets the internal `rnmie` state bit, which
reenables other interrupts.

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

NOTE: Traps in the RNMI handler can only be resumed if they occur while
the handler was servicing an interrupt that occured outside of
machine-mode.

== Interaction with debugger

The debugger can be configured such that an RNMI event drops the
system into the debugger.





Re: Resumable NMI proposal

Jonathan Behrens <behrensj@...>
 

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


On Tue, Jan 19, 2021 at 11:42 AM Brian Grayson via lists.riscv.org <brian.grayson=sifive.com@...> wrote:
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 need, and then unblock further NMIs, i.e., they might be stackable in some cases. This spec precludes that by making rnmie not software-writable.

I also fundamentally dislike the use of the term "non-maskable", because the proposed rnmie bit literally masks non-maskable interrupts. That's an impossible thing to put into a spec, as remarked upon in your NOTE.

From a prior art point of view, the PowerPC Book E architecture (the embedded flavor) handled this differently. It called NMIs "critical interrupts", and all critical interrupts are higher priority than non-critical. They can be masked, and further critical interrupts are automatically masked when a critical interrupt is taken, but software in the critical interrupt handler can save the state it needs, and then re-enable further critical interrupts if that is desired. I believe this is ultimately the desired behavior for us as well, and is IMO better architectural terminology and a better mental framework.

Within non-critical interrupts, some debug events were considered highest priority, some were considered lowest priority, depending on the type of debug event. It can be difficult (or even impossible) to assert that all debug events are all higher or all lower than a given exception event.

See Chapter 7 "Interrupts and Exceptions" of https://www.nxp.com/docs/en/user-guide/BOOK_EUM.pdf for more details, and in particular 7.9.1 that talks about the relative priority of all the different types of interrupts in both classes, and where various debug interrupts fell.

Back to the proposal, I think there's a mistake near the end:

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

If the enable bit is clear, the exception can't be taken, right? Is this supposed to discuss the case of an ordinary exception being observed while in RNMI, where the exception will actually be instantly taken once we leave RNMI state, in which case we would jump to the ordinary exception handler? Or am I misunderstanding?

Brian

On Mon, Jan 18, 2021 at 9:09 PM Greg Favor <gfavor@...> wrote:
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 enabled)?

- The width of the mnstatus CSR is not explicitly defined (e.g. as an XLEN-bit or 32-bit read-write register).

- What is the relative priority for RNMI versus Debug Halt Request?  Maybe it is the responsibility ultimately for the Debug spec to specify this (?), but what should be said over there?

- Can you briefly comment on the types of systems that show the most need for recoverable NMIs (versus being not ideal but ok with the current NMI situation).  Semi-equivalently, would you expect this extension to eventually become a requirement (or optional) in RVA22 and/or RVM22?

Greg

On Mon, Jan 18, 2021 at 6:39 PM Krste Asanovic <krste@...> wrote:

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 for discussion, but I think it is small enough to go
through fast track process.

Krste

:sectnums:
:toc: left

= Resumable NMI support in RISC-V
Version 0.2.1-Draft

== Background and Motivation

The RISC-V privileged architecture version 1.11 supports only
unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
handler in machine mode, overwriting the current `mepc` and `mcause`
register values.  If the hart had been executing machine-mode code in
a trap handler, the previous values in `mepc` and `mcause` would not
be recoverable and so execution is not generally resumable.

This proposal adds support for resumable non-maskable interrupts
(RNMIs) to RISC-V.  The extension adds four new CSRs (`mnepc`,
`mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
and a new instruction to resume from the RNMI handler.

== RNMI Interrupt Signals

The `rnmi` interrupt signals are inputs to
the hart.  These interrupts have higher priority than any other
interrupt or exception on the hart and cannot be disabled by software.
Specifically, they are not disabled by clearing the `mstatus.mie`
register.

== RNMI Handler Addresses

The RNMI interrupt trap handler address is implementation-defined.

RNMI also has an associated exception trap handler address, which is
implementation defined.

== New RNMI CSRs

This proposal adds additional M-mode CSRs to enable a resumable
non-maskable interrupt (RNMI).

.NMI additional CSRs
[cols="2,2,2,2"]
[%autowidth]
|===
| Number | Privilege | Name        | Description

| 0x350  | MRW       | `mnscratch` | Resumable Non-maskable scratch register
| 0x351  | MRW       | `mnepc`     | Resumable Non-maskable EPC value
| 0x352  | MRW       | `mncause`   | Resumable Non-maskable cause value
| 0x353  | MRW       | `mnstatus`  | Resumable Non-maskable status
|===

The `mnscratch` CSR holds an XLEN-bit read-write register which
enables the NMI trap handler to save and restore the context that was
interrupted.

The `mnepc` CSR is an XLEN-bit read-write register which on entry
to the NMI trap handler holds the PC of the instruction that took the
interrupt. The lowest bit of `mnepc` is hardwired to zero.

The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
1, and the NMI cause encoded in the least-significant bits or zero if
NMI causes are not supported.

The `mnstatus` CSR holds a two-bit field which on entry to the trap
handler holds the privilege mode of the interrupted context encoded in
bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`.  The other
bits in `mnstatus` are _reserved_, but software should write zeros and
hardware implementations should return zeros.

== New MNRET instruction

This new M-mode only instruction uses the values in `mnepc` and
`mnstatus` to return to the program counter and privileged mode of the
interrupted context respectively.  This instruction also sets the
`rnmie` state bit.

MNRET instruction encoding is same as MRET except with bit 30 set
(i.e.,`funct7`=`0111000`).

== RNMI Operation

When an RNMI interrupt is detected, the interrupted PC is written to
the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
privilege mode of the interrupted context to the `mnstatus` CSR.  An
internal microarchitectural state bit `rnmie` is cleared to indicate
that processor is in an RNMI handler and cannot take a new RNMI
interrupt.  The internal `rnmie` bit when clear also disables all
other interrupts.

NOTE: These interrupts are called non-maskable because software cannot
mask the interrupts, but for correct operation other instances of the
same interrupt must be held off until the handler is completed, hence
the internal state bit.

The core then enters machine-mode and jumps to the RNMI trap handler
address.

The RNMI handler can resume original execution using the new MNRET
instruction, which restores the PC from `mnepc`, the privilege mode
from `mnstatus`, and also sets the internal `rnmie` state bit, which
reenables other interrupts.

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

NOTE: Traps in the RNMI handler can only be resumed if they occur while
the handler was servicing an interrupt that occured outside of
machine-mode.

== Interaction with debugger

The debugger can be configured such that an RNMI event drops the
system into the debugger.






Re: Resumable NMI proposal

Brian Grayson
 

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 need, and then unblock further NMIs, i.e., they might be stackable in some cases. This spec precludes that by making rnmie not software-writable.

I also fundamentally dislike the use of the term "non-maskable", because the proposed rnmie bit literally masks non-maskable interrupts. That's an impossible thing to put into a spec, as remarked upon in your NOTE.

From a prior art point of view, the PowerPC Book E architecture (the embedded flavor) handled this differently. It called NMIs "critical interrupts", and all critical interrupts are higher priority than non-critical. They can be masked, and further critical interrupts are automatically masked when a critical interrupt is taken, but software in the critical interrupt handler can save the state it needs, and then re-enable further critical interrupts if that is desired. I believe this is ultimately the desired behavior for us as well, and is IMO better architectural terminology and a better mental framework.

Within non-critical interrupts, some debug events were considered highest priority, some were considered lowest priority, depending on the type of debug event. It can be difficult (or even impossible) to assert that all debug events are all higher or all lower than a given exception event.

See Chapter 7 "Interrupts and Exceptions" of https://www.nxp.com/docs/en/user-guide/BOOK_EUM.pdf for more details, and in particular 7.9.1 that talks about the relative priority of all the different types of interrupts in both classes, and where various debug interrupts fell.

Back to the proposal, I think there's a mistake near the end:

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

If the enable bit is clear, the exception can't be taken, right? Is this supposed to discuss the case of an ordinary exception being observed while in RNMI, where the exception will actually be instantly taken once we leave RNMI state, in which case we would jump to the ordinary exception handler? Or am I misunderstanding?

Brian

On Mon, Jan 18, 2021 at 9:09 PM Greg Favor <gfavor@...> wrote:
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 enabled)?

- The width of the mnstatus CSR is not explicitly defined (e.g. as an XLEN-bit or 32-bit read-write register).

- What is the relative priority for RNMI versus Debug Halt Request?  Maybe it is the responsibility ultimately for the Debug spec to specify this (?), but what should be said over there?

- Can you briefly comment on the types of systems that show the most need for recoverable NMIs (versus being not ideal but ok with the current NMI situation).  Semi-equivalently, would you expect this extension to eventually become a requirement (or optional) in RVA22 and/or RVM22?

Greg

On Mon, Jan 18, 2021 at 6:39 PM Krste Asanovic <krste@...> wrote:

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 for discussion, but I think it is small enough to go
through fast track process.

Krste

:sectnums:
:toc: left

= Resumable NMI support in RISC-V
Version 0.2.1-Draft

== Background and Motivation

The RISC-V privileged architecture version 1.11 supports only
unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
handler in machine mode, overwriting the current `mepc` and `mcause`
register values.  If the hart had been executing machine-mode code in
a trap handler, the previous values in `mepc` and `mcause` would not
be recoverable and so execution is not generally resumable.

This proposal adds support for resumable non-maskable interrupts
(RNMIs) to RISC-V.  The extension adds four new CSRs (`mnepc`,
`mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
and a new instruction to resume from the RNMI handler.

== RNMI Interrupt Signals

The `rnmi` interrupt signals are inputs to
the hart.  These interrupts have higher priority than any other
interrupt or exception on the hart and cannot be disabled by software.
Specifically, they are not disabled by clearing the `mstatus.mie`
register.

== RNMI Handler Addresses

The RNMI interrupt trap handler address is implementation-defined.

RNMI also has an associated exception trap handler address, which is
implementation defined.

== New RNMI CSRs

This proposal adds additional M-mode CSRs to enable a resumable
non-maskable interrupt (RNMI).

.NMI additional CSRs
[cols="2,2,2,2"]
[%autowidth]
|===
| Number | Privilege | Name        | Description

| 0x350  | MRW       | `mnscratch` | Resumable Non-maskable scratch register
| 0x351  | MRW       | `mnepc`     | Resumable Non-maskable EPC value
| 0x352  | MRW       | `mncause`   | Resumable Non-maskable cause value
| 0x353  | MRW       | `mnstatus`  | Resumable Non-maskable status
|===

The `mnscratch` CSR holds an XLEN-bit read-write register which
enables the NMI trap handler to save and restore the context that was
interrupted.

The `mnepc` CSR is an XLEN-bit read-write register which on entry
to the NMI trap handler holds the PC of the instruction that took the
interrupt. The lowest bit of `mnepc` is hardwired to zero.

The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
1, and the NMI cause encoded in the least-significant bits or zero if
NMI causes are not supported.

The `mnstatus` CSR holds a two-bit field which on entry to the trap
handler holds the privilege mode of the interrupted context encoded in
bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`.  The other
bits in `mnstatus` are _reserved_, but software should write zeros and
hardware implementations should return zeros.

== New MNRET instruction

This new M-mode only instruction uses the values in `mnepc` and
`mnstatus` to return to the program counter and privileged mode of the
interrupted context respectively.  This instruction also sets the
`rnmie` state bit.

MNRET instruction encoding is same as MRET except with bit 30 set
(i.e.,`funct7`=`0111000`).

== RNMI Operation

When an RNMI interrupt is detected, the interrupted PC is written to
the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
privilege mode of the interrupted context to the `mnstatus` CSR.  An
internal microarchitectural state bit `rnmie` is cleared to indicate
that processor is in an RNMI handler and cannot take a new RNMI
interrupt.  The internal `rnmie` bit when clear also disables all
other interrupts.

NOTE: These interrupts are called non-maskable because software cannot
mask the interrupts, but for correct operation other instances of the
same interrupt must be held off until the handler is completed, hence
the internal state bit.

The core then enters machine-mode and jumps to the RNMI trap handler
address.

The RNMI handler can resume original execution using the new MNRET
instruction, which restores the PC from `mnepc`, the privilege mode
from `mnstatus`, and also sets the internal `rnmie` state bit, which
reenables other interrupts.

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

NOTE: Traps in the RNMI handler can only be resumed if they occur while
the handler was servicing an interrupt that occured outside of
machine-mode.

== Interaction with debugger

The debugger can be configured such that an RNMI event drops the
system into the debugger.






Re: Resumable NMI proposal

Greg Favor
 

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 enabled)?

- The width of the mnstatus CSR is not explicitly defined (e.g. as an XLEN-bit or 32-bit read-write register).

- What is the relative priority for RNMI versus Debug Halt Request?  Maybe it is the responsibility ultimately for the Debug spec to specify this (?), but what should be said over there?

- Can you briefly comment on the types of systems that show the most need for recoverable NMIs (versus being not ideal but ok with the current NMI situation).  Semi-equivalently, would you expect this extension to eventually become a requirement (or optional) in RVA22 and/or RVM22?

Greg

On Mon, Jan 18, 2021 at 6:39 PM Krste Asanovic <krste@...> wrote:

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 for discussion, but I think it is small enough to go
through fast track process.

Krste

:sectnums:
:toc: left

= Resumable NMI support in RISC-V
Version 0.2.1-Draft

== Background and Motivation

The RISC-V privileged architecture version 1.11 supports only
unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
handler in machine mode, overwriting the current `mepc` and `mcause`
register values.  If the hart had been executing machine-mode code in
a trap handler, the previous values in `mepc` and `mcause` would not
be recoverable and so execution is not generally resumable.

This proposal adds support for resumable non-maskable interrupts
(RNMIs) to RISC-V.  The extension adds four new CSRs (`mnepc`,
`mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
and a new instruction to resume from the RNMI handler.

== RNMI Interrupt Signals

The `rnmi` interrupt signals are inputs to
the hart.  These interrupts have higher priority than any other
interrupt or exception on the hart and cannot be disabled by software.
Specifically, they are not disabled by clearing the `mstatus.mie`
register.

== RNMI Handler Addresses

The RNMI interrupt trap handler address is implementation-defined.

RNMI also has an associated exception trap handler address, which is
implementation defined.

== New RNMI CSRs

This proposal adds additional M-mode CSRs to enable a resumable
non-maskable interrupt (RNMI).

.NMI additional CSRs
[cols="2,2,2,2"]
[%autowidth]
|===
| Number | Privilege | Name        | Description

| 0x350  | MRW       | `mnscratch` | Resumable Non-maskable scratch register
| 0x351  | MRW       | `mnepc`     | Resumable Non-maskable EPC value
| 0x352  | MRW       | `mncause`   | Resumable Non-maskable cause value
| 0x353  | MRW       | `mnstatus`  | Resumable Non-maskable status
|===

The `mnscratch` CSR holds an XLEN-bit read-write register which
enables the NMI trap handler to save and restore the context that was
interrupted.

The `mnepc` CSR is an XLEN-bit read-write register which on entry
to the NMI trap handler holds the PC of the instruction that took the
interrupt. The lowest bit of `mnepc` is hardwired to zero.

The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
1, and the NMI cause encoded in the least-significant bits or zero if
NMI causes are not supported.

The `mnstatus` CSR holds a two-bit field which on entry to the trap
handler holds the privilege mode of the interrupted context encoded in
bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`.  The other
bits in `mnstatus` are _reserved_, but software should write zeros and
hardware implementations should return zeros.

== New MNRET instruction

This new M-mode only instruction uses the values in `mnepc` and
`mnstatus` to return to the program counter and privileged mode of the
interrupted context respectively.  This instruction also sets the
`rnmie` state bit.

MNRET instruction encoding is same as MRET except with bit 30 set
(i.e.,`funct7`=`0111000`).

== RNMI Operation

When an RNMI interrupt is detected, the interrupted PC is written to
the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
privilege mode of the interrupted context to the `mnstatus` CSR.  An
internal microarchitectural state bit `rnmie` is cleared to indicate
that processor is in an RNMI handler and cannot take a new RNMI
interrupt.  The internal `rnmie` bit when clear also disables all
other interrupts.

NOTE: These interrupts are called non-maskable because software cannot
mask the interrupts, but for correct operation other instances of the
same interrupt must be held off until the handler is completed, hence
the internal state bit.

The core then enters machine-mode and jumps to the RNMI trap handler
address.

The RNMI handler can resume original execution using the new MNRET
instruction, which restores the PC from `mnepc`, the privilege mode
from `mnstatus`, and also sets the internal `rnmie` state bit, which
reenables other interrupts.

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

NOTE: Traps in the RNMI handler can only be resumed if they occur while
the handler was servicing an interrupt that occured outside of
machine-mode.

== Interaction with debugger

The debugger can be configured such that an RNMI event drops the
system into the debugger.






Resumable NMI proposal

Krste Asanovic
 

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 for discussion, but I think it is small enough to go
through fast track process.

Krste

:sectnums:
:toc: left

= Resumable NMI support in RISC-V
Version 0.2.1-Draft

== Background and Motivation

The RISC-V privileged architecture version 1.11 supports only
unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
handler in machine mode, overwriting the current `mepc` and `mcause`
register values. If the hart had been executing machine-mode code in
a trap handler, the previous values in `mepc` and `mcause` would not
be recoverable and so execution is not generally resumable.

This proposal adds support for resumable non-maskable interrupts
(RNMIs) to RISC-V. The extension adds four new CSRs (`mnepc`,
`mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
and a new instruction to resume from the RNMI handler.

== RNMI Interrupt Signals

The `rnmi` interrupt signals are inputs to
the hart. These interrupts have higher priority than any other
interrupt or exception on the hart and cannot be disabled by software.
Specifically, they are not disabled by clearing the `mstatus.mie`
register.

== RNMI Handler Addresses

The RNMI interrupt trap handler address is implementation-defined.

RNMI also has an associated exception trap handler address, which is
implementation defined.

== New RNMI CSRs

This proposal adds additional M-mode CSRs to enable a resumable
non-maskable interrupt (RNMI).

.NMI additional CSRs
[cols="2,2,2,2"]
[%autowidth]
|===
| Number | Privilege | Name | Description

| 0x350 | MRW | `mnscratch` | Resumable Non-maskable scratch register
| 0x351 | MRW | `mnepc` | Resumable Non-maskable EPC value
| 0x352 | MRW | `mncause` | Resumable Non-maskable cause value
| 0x353 | MRW | `mnstatus` | Resumable Non-maskable status
|===

The `mnscratch` CSR holds an XLEN-bit read-write register which
enables the NMI trap handler to save and restore the context that was
interrupted.

The `mnepc` CSR is an XLEN-bit read-write register which on entry
to the NMI trap handler holds the PC of the instruction that took the
interrupt. The lowest bit of `mnepc` is hardwired to zero.

The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
1, and the NMI cause encoded in the least-significant bits or zero if
NMI causes are not supported.

The `mnstatus` CSR holds a two-bit field which on entry to the trap
handler holds the privilege mode of the interrupted context encoded in
bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`. The other
bits in `mnstatus` are _reserved_, but software should write zeros and
hardware implementations should return zeros.

== New MNRET instruction

This new M-mode only instruction uses the values in `mnepc` and
`mnstatus` to return to the program counter and privileged mode of the
interrupted context respectively. This instruction also sets the
`rnmie` state bit.

MNRET instruction encoding is same as MRET except with bit 30 set
(i.e.,`funct7`=`0111000`).

== RNMI Operation

When an RNMI interrupt is detected, the interrupted PC is written to
the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
privilege mode of the interrupted context to the `mnstatus` CSR. An
internal microarchitectural state bit `rnmie` is cleared to indicate
that processor is in an RNMI handler and cannot take a new RNMI
interrupt. The internal `rnmie` bit when clear also disables all
other interrupts.

NOTE: These interrupts are called non-maskable because software cannot
mask the interrupts, but for correct operation other instances of the
same interrupt must be held off until the handler is completed, hence
the internal state bit.

The core then enters machine-mode and jumps to the RNMI trap handler
address.

The RNMI handler can resume original execution using the new MNRET
instruction, which restores the PC from `mnepc`, the privilege mode
from `mnstatus`, and also sets the internal `rnmie` state bit, which
reenables other interrupts.

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

NOTE: Traps in the RNMI handler can only be resumed if they occur while
the handler was servicing an interrupt that occured outside of
machine-mode.

== Interaction with debugger

The debugger can be configured such that an RNMI event drops the
system into the debugger.


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

Bill Huffman
 

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

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Allen Baum
Sent: Tuesday, December 15, 2020 12:01 PM
To: Richard Trauben <rtrauben@...>
Cc: anne.merlande@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] MPIE and MPP update when returning from interrupt with MRET

 

EXTERNAL MAIL

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 stack.

Whichever mode you return to, you can always set PP to either your own mode, or a lower priv level, but not higher, and this ensures it doesn't start out higher.

 

The absence of which mode you are in is quite deliberate: its existence is a virtualization hole.

 

On Tue, Dec 15, 2020 at 11:48 AM Richard Trauben <rtrauben@...> wrote:

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 handler and set the callera privilege level

in the *PP field to q non-U mode which calls the non-M mode handler.

 

Please provide the spec name, version, chapter, page, paragraph and sentence so an editor can consider details to clarify the reference. 

 

for me, the more problematic

issue was there was no psr

to identify the privilege of the

caller. technically however it is implicit and it’s assumed the code knows the privilege it was written for. it’s ok once you get used to the convention.

 

Richard

 

 



On Dec 15, 2020, at 7:18 AM, Anne MERLANDE via lists.riscv.org <anne.merlande=st.com@...> wrote:

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 nested traps ? In case of an implementation with 2 privileged modes but no N extension is it still necessary ?

Thanks for your help
Anne


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

Allen Baum
 

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 stack.
Whichever mode you return to, you can always set PP to either your own mode, or a lower priv level, but not higher, and this ensures it doesn't start out higher.

The absence of which mode you are in is quite deliberate: its existence is a virtualization hole.

On Tue, Dec 15, 2020 at 11:48 AM Richard Trauben <rtrauben@...> wrote:
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 handler and set the callera privilege level
in the *PP field to q non-U mode which calls the non-M mode handler.

Please provide the spec name, version, chapter, page, paragraph and sentence so an editor can consider details to clarify the reference. 

for me, the more problematic
issue was there was no psr
to identify the privilege of the
caller. technically however it is implicit and it’s assumed the code knows the privilege it was written for. it’s ok once you get used to the convention.

Richard




On Dec 15, 2020, at 7:18 AM, Anne MERLANDE via lists.riscv.org <anne.merlande=st.com@...> wrote:

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 nested traps ? In case of an implementation with 2 privileged modes but no N extension is it still necessary ?

Thanks for your help
Anne


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

Richard Trauben
 

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 handler and set the callera privilege level
in the *PP field to q non-U mode which calls the non-M mode handler.

Please provide the spec name, version, chapter, page, paragraph and sentence so an editor can consider details to clarify the reference. 

for me, the more problematic
issue was there was no psr
to identify the privilege of the
caller. technically however it is implicit and it’s assumed the code knows the privilege it was written for. it’s ok once you get used to the convention.

Richard




On Dec 15, 2020, at 7:18 AM, Anne MERLANDE via lists.riscv.org <anne.merlande=st.com@...> wrote:

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 nested traps ? In case of an implementation with 2 privileged modes but no N extension is it still necessary ?

Thanks for your help
Anne


MPIE and MPP update when returning from interrupt with MRET

Anne MERLANDE
 

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 nested traps ? In case of an implementation with 2 privileged modes but no N extension is it still necessary ?

Thanks for your help
Anne


ePMP update

Joe Xie
 

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 there’re a few more specs to review and approve. We are trying to find ways to accelerate the approval process.
 
Spec update to support shared RO region
 
As some of you may aware, the TG had been discussing how to support shared RO region between M and sub-M mode.
 
After two meetings we tentatively concluded to propose repurposing LWRX = 1111 for shared RO region. The spec is updated with the new proposal, thanks to @Nick Kossifidis. And I copied the words here
 
The encoding pmpcfg.LRWX=1111 can be used for sharing data between M-mode and S/U mode, where both modes only have read-only access to the region. The region remains locked so that any further modifications to the configuration or address registers are ignored until a hard reset, unless mseccfg.RLB is set.
 
Please kindly review the change and provide feedback, I am also adding Andrew and tech-priv group for the review too. As usual we would need to start a new poll for the additional change, the poll will be started today and last for two weeks. After that, if it is approved, we would move on to update Spike, test-suit, SAIL model..etc.
 
Thanks,
Joe
 
 


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

Greg Favor
 

On Wed, Dec 9, 2020 at 3:09 PM Sanjay Patel <spatel@...> wrote:

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 privileged workgroup.


Yes.
 

Is there an approximate timeline?


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

Greg

 


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

Sanjay Patel <spatel@...>
 

(+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 privileged workgroup. Is there an approximate timeline?

 

Sanjay

 

From: Greg Favor <gfavor@...>
Date: Wednesday, December 9, 2020 at 2:09 PM
To: Sanjay Patel <spatel@...>
Cc: "tech-privileged@..." <tech-privileged@...>
Subject: [EXTERNAL]Re: [RISC-V] [tech-privileged] Performance Monitor Interrupts

 

On Wed, Dec 9, 2020 at 1:25 PM Sanjay Patel <spatel@...> wrote:

I have some questions about the hpm CSRs.

 

·         There is a conspicuous lack of an interrupt associated with a counter overflow.  Are custom interrupts expected to be provided in a RISC-V implementation?

Fancy you should ask. :)  A fast-track extension is being put together (and going thru some pre-review by a couple of key people) and hopefully should be put to initial public review very soon.  That extension will strive to standardize generating interrupts on counter overflows.  But thus far the architecture says nothing about this topic and hence anything done today by implementations in this regard is custom (and an implementation is free to do whatever it wants).

 

·          

·         What model does Linux perf assume for the use of the monitors? Does a standard release not use interrupts and if so, is polling used instead?

This overflow interrupt capability is a missing architectural feature that other architectures have, and Linux perf supports, and needs to be added to RISC-V to bring it on par with everyone else.  As far as what happens for RISC-V in Linux perf in this particular regard, I'll let a software person provide a proper answer.

 

·          

·         An SBI interface would seem to be needed for Supervisor/Linux to set the events? Is there a standard call defined?

In today's architecture the hpmcounter CSRs and the associated mhpmevent CSRs can only be written in M-mode.  An OpenSBI extension is currently in progress of being added to OpenSBI to support setting of these CSRs by lower privilege modes.

 

Greg

 


Re: Performance Monitor Interrupts

Greg Favor
 

On Wed, Dec 9, 2020 at 1:25 PM Sanjay Patel <spatel@...> wrote:

I have some questions about the hpm CSRs.

 

  • There is a conspicuous lack of an interrupt associated with a counter overflow.  Are custom interrupts expected to be provided in a RISC-V implementation?
Fancy you should ask. :)  A fast-track extension is being put together (and going thru some pre-review by a couple of key people) and hopefully should be put to initial public review very soon.  That extension will strive to standardize generating interrupts on counter overflows.  But thus far the architecture says nothing about this topic and hence anything done today by implementations in this regard is custom (and an implementation is free to do whatever it wants).
 
  • What model does Linux perf assume for the use of the monitors? Does a standard release not use interrupts and if so, is polling used instead?
This overflow interrupt capability is a missing architectural feature that other architectures have, and Linux perf supports, and needs to be added to RISC-V to bring it on par with everyone else.  As far as what happens for RISC-V in Linux perf in this particular regard, I'll let a software person provide a proper answer.
 
  • An SBI interface would seem to be needed for Supervisor/Linux to set the events? Is there a standard call defined?
In today's architecture the hpmcounter CSRs and the associated mhpmevent CSRs can only be written in M-mode.  An OpenSBI extension is currently in progress of being added to OpenSBI to support setting of these CSRs by lower privilege modes.

Greg


Re: Performance Monitor Interrupts

mark
 

+platform

--------
sent from a mobile device. please forgive any typos.

On Dec 9, 2020, at 1:25 PM, Sanjay Patel <spatel@...> wrote:



 

Hi,

 

I have some questions about the hpm CSRs.

 

  • There is a conspicuous lack of an interrupt associated with a counter overflow.  Are custom interrupts expected to be provided in a RISC-V implementation?
  • What model does Linux perf assume for the use of the monitors? Does a standard release not use interrupts and if so, is polling used instead?
  • An SBI interface would seem to be needed for Supervisor/Linux to set the events? Is there a standard call defined?

 

This link alludes to similar issues, but it also says RISC-V implementations exist w/o an interrupt capabilty.

https://www.kernel.org/doc/html/latest/riscv/pmu.html

 

Thanks,

Sanjay

 

 


Performance Monitor Interrupts

Sanjay Patel <spatel@...>
 

 

Hi,

 

I have some questions about the hpm CSRs.

 

  • There is a conspicuous lack of an interrupt associated with a counter overflow.  Are custom interrupts expected to be provided in a RISC-V implementation?
  • What model does Linux perf assume for the use of the monitors? Does a standard release not use interrupts and if so, is polling used instead?
  • An SBI interface would seem to be needed for Supervisor/Linux to set the events? Is there a standard call defined?

 

This link alludes to similar issues, but it also says RISC-V implementations exist w/o an interrupt capabilty.

https://www.kernel.org/doc/html/latest/riscv/pmu.html

 

Thanks,

Sanjay

 

 

781 - 800 of 1210