question on NMI

[Jerry Ho]

Hi, 

Recently I am reading "The RISC-V Instruction Set Manual Volume II: Privileged Architecture". Inside the NMI section, there are some following description:

"The mepc register is written with the address of the next instruction to be executed at the time the NMI was taken, and mcause is set to a value indicating the source of the NMI"

I have the following question:

if there are some trap(interrupt) happening and the corresponding ISR is executing, and NMI happens. The NMI will write the mepc, but at this time, the interrupted ISR didnt back up the mepc it previously wrote to somewhere else, now when the NMI ends, the interrupted ISR will have no idea where it should return.

Am i right? Or the backup process is define by the implementation? Any comment will be highly appreciated!

[Tommy Murphy]

I don't think that the spec says it but the following suggests that NMI is not recoverable in which case the scenario that you raise is moot?

https://github.com/riscv/riscv-isa-manual/issues/261

[Krste Asanovic]

Existing NMI is not recoverable (UNMI)

There is a proposal in flight as part of priv-1.12 update to add a recoverable NMI (RNMI) as an extension.

Krste

On Nov 18, 2019, at 5:04 AM, Tommy Murphy <tommy_...@hotmail.com> wrote:

I don't think that the spec says it but the following suggests that NMI is not recoverable in which case the scenario that you raise is moot?

https://github.com/riscv/riscv-isa-manual/issues/261

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/1d7006bc-b4f1-4263-bdb6-8aa582e1ccd8%40groups.riscv.org.

[Tommy Murphy]

Thanks for the clarification Krste.

But just to be pedantic I don't see where the 20190608-Priv-MSU-Ratified spec explicitly says that NMI is unrecoverable or am I missing something?

[Krste Asanovic]

It is not explicitly described in this version of the spec, but the text in 3.4 does state that it can overwrite state in an existing interrupt handler.

If the NMI occurs when mepc and mcause are known not to be in use (outside handler, or have already been saved), the NMI can be recovered, but not in general.

Krste

[Tommy Murphy]

On Monday, 18 November 2019 14:15:14 UTC, krste wrote:

It is not explicitly described in this version of the spec, but the text in 3.4 does state that it can overwrite state in an existing interrupt handler.

If the NMI occurs when mepc and mcause are known not to be in use (outside handler, or have already been saved), the NMI can be recovered, but not in general.

OK - thanks for the further clarification.

In effect that means that the current ratified spec only supports NMI being recoverable if no interrupts are used at all since NMI is asynchronous and cannot be held off to allow an ISR to save the necessary state to allow the ISR interrupted by NMI to be recoverable.

Is that correct?

 

[Krste Asanovic]

Right, current NMI is not guaranteed to be recoverable.

There could be systems where “probably” recoverable is adequate for use case:

Eg., if mstatus.mpp was not M-mode, then should be recoverable.

If in M-mode, and mstatus.mpie is set, then should also be recoverable.

Only if in M-mode and mstatus.mpie is clear are NMIs not recoverable.

Krste

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/58b50844-1940-44d5-87a6-0daa7dc22579%40groups.riscv.org.

[Jerry Ho]

Thanks for your reply, Krste. But if it is not recoverable, why "The mepc register is written with the address of the next instruction to be executed at the time the NMI was taken, and mcause is set to a value indicating the source of the NMI". As far as i can understand, if its not recoverable, then there will be no need to write the corresponding address to the mepc. Also, when an NMI happens, according to this spec, the only option will be shut down of the whole system. Is this the case? Thanks for calrifying 

在 2019年11月18日星期一 UTC+8下午9:06:35，krste写道：

Existing NMI is not recoverable (UNMI)

There is a proposal in flight as part of priv-1.12 update to add a recoverable NMI (RNMI) as an extension.

Krste

On Nov 18, 2019, at 5:04 AM, Tommy Murphy <tommy_...@hotmail.com> wrote:

I don't think that the spec says it but the following suggests that NMI is not recoverable in which case the scenario that you raise is moot?

https://github.com/riscv/riscv-isa-manual/issues/261

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa...@groups.riscv.org.

[kr...@berkeley.edu]

>>>>> On Mon, 18 Nov 2019 18:08:50 -0800 (PST), Jerry Ho <jerry...@gmail.com> said:

| Thanks for your reply, Krste. But if it is not recoverable, why "The mepc register is written with the address
| of the next instruction to be executed at the time the NMI was taken, and mcause is set to a value indicating
| the source of the NMI". As far as i can understand, if its not recoverable, then there will be no need to
| write the corresponding address to the mepc. Also, when an NMI happens, according to this spec, the only
| option will be shut down of the whole system. Is this the case?
| Thanks for calrifying 

Typically the system will want to try to save/log the error location
and cause to help diagnose the failure, before reset or shutdown.

Also, these NMI events are only unrecoverable when in M-mode with
interrupts disabled, which would usually be expected to be a small
fraction of overall run time. Other cases might allow recovery after
error logging.

Krste

| 在 2019年11月18日星期一 UTC+8下午9:06:35，krste写道：

| Existing NMI is not recoverable (UNMI)

| There is a proposal in flight as part of priv-1.12 update to add a recoverable NMI (RNMI) as an extension.

| Krste

| On Nov 18, 2019, at 5:04 AM, Tommy Murphy <tommy_...@hotmail.com> wrote:

| I don't think that the spec says it but the following suggests that NMI is not recoverable in which
| case the scenario that you raise is moot?

| https://github.com/riscv/riscv-isa-manual/issues/261

| --
| You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email to isa...@groups.
| riscv.org.
| To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/
| 1d7006bc-b4f1-4263-bdb6-8aa582e1ccd8%40groups.riscv.org.

| --
| You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email to

| isa-dev+u...@groups.riscv.org.

| To view this discussion on the web visit

| https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/a197b4e7-5f71-49be-a48d-0ea5baf8f476%40groups.riscv.org
| .

[Allen Baum]

Depending on what you expect NMI to be used for, it may not matter that it is unrecoverable.

My expectation is that it is used for irrecoverable HW faults (e.g. double errors when reading from a SECDED memory or in victim buffer, or ECC error on a cache or WB buffer tag,  or garbled transaction ID in a response, or watchdog timer overflow ) - in those cases, you probably can't recover anyway (you might be able to shut down a process in the first case, but in the other cases it may not even be clear which process to shut down).

There will likely be platforms that use NMI for critical real-time events that must interrupt quickly and recoverably. 

For that you need to either guarantee that 

 - M-code routines have bounded latencies that are less than "quickly", or 

 - there is the new recoverable NMI extension that Krste mentioned.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/24019.30690.252175.48101%40KAiMac.local.

[Samuel Falvo II]

Wouldn't just hard-wiring a few bits in the xIE registers to 1 suffice to make it a recoverable NMI?  It's not clear to me that a complete extension would need to be specified to support this feature.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DD81Vw8_yEhWx6pSVWALe32g_ezdYH7jUgMuXApdph4-g%40mail.gmail.com.

--

Samuel A. Falvo II

[Allen Baum]

No; if  trap is taken to M-mode, and an NMI is taken, then you overwrite mepc (at least) - and then you can return to m-mode, but not to whoever called m-mode. There are a couple of ways around that, depending on the use cases for NMI, as I outlined above.

[Samuel Falvo II]

I'm confused by this; what you wrote is clear to me, but seems to be answering a question I didn't ask.  I'm talking about the xIE registers, not the xIE fields in the respective xSTATUS registers.  Hopefully that clears things up.

P.S.: I do recall raising concerns over having fields named the same as registers in the past, and predicted that it'd lead to confusion in discussions eventually.  Well, here it is.  ;-)

[Allen Baum]

I'm not sure if this is a response to me, since I didn't mention xie CSR bits nor xSTATUS.xie bits. 

But forcing either of them to 1 would not solve the problem of an NMI arriving while a hart was  in m-mode because of an eCall from some other mode. mEPC  will be overwritten, and you can not return to the code that called m-code- which sounds rather fatal to that code.

The use case that the spec defines for NMI is:

   Non-maskable interrupts (NMIs) are only used for hardware error conditions 

(which I would expect that should be specifically uncorrectable/fatal error conditions). 

Those error conditions are usually asynchronous to the code running at the time of the interrupt (which is why it is an interrupt and not an exception), so generally not recoverable, but possibly containable - which is what the NMI handler will attempt to do.

There are other use models for an NMI, but without the extension that Krste has mentioned, it would be difficult to shoehorn that into the current definition.

Note that Intel (and probably other architectures) have the concept of a double fault, e.g., a fault that is signalled when a core is handling some other fault.

That can only be handled by a reset of some kind, (or perhaps a separate vector, but then you still need to define a triple-fault)

[Jacob Lifshay]

On Tue, Nov 19, 2019, 12:19 Allen Baum <allen...@esperantotech.com> wrote:

There are other use models for an NMI, but without the extension that Krste has mentioned, it would be difficult to shoehorn that into the current definition.

Note that Intel (and probably other architectures) have the concept of a double fault, e.g., a fault that is signalled when a core is handling some other fault.

That can only be handled by a reset of some kind, (or perhaps a separate vector, but then you still need to define a triple-fault)

x86 has a separate double-fault handler, if there's a triple-fault, then it's an automatic CPU reset (or maybe system reset, not sure).

Jacob

[Tommy Murphy]

FWIW (maybe nothing :-) Cortex-M will also end up in lockup with its LOCKUP signal asserted if a double fault occurs - e.g. exception during the execution of a hardfault or NMI handler.

[Allen Baum]

So there are two different use cases; one is to be able to do a postmortem of what happened. Lockup may be the best way to do that, but that's perhaps not wehat yu want to do for a cardiac monitor or a spacecraft.

Those other use cases ( workload is critica) make it imperative that things restart as quickly as possible. Reset is the best way to do that. 

Intel had a special kind of reset that cleared out as minimal status as possible so to leave enough breadcrumbs that someone could go in and do some level of postmortem. That enable either approach, assuming that it has some way of self-reseting.

[Jeff Scott]

Hi Krste,

 

Could you give an update on RNMI extension?  Is it documented?

 

Jeff

 

From: Krste Asanovic <kr...@berkeley.edu>
Sent: Monday, November 18, 2019 7:06 AM
To: Tommy Murphy <tommy_...@hotmail.com>
Cc: RISC-V ISA Dev <isa...@groups.riscv.org>
Subject: [EXT] Re: [isa-dev] Re: question on NMI

 

Caution: EXT Email

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/B32F0ECC-8B03-4610-8323-69DB8CECCE35%40berkeley.edu.

[Jeff Scott]

Hi Krste,

 

Gentle reminder on this query.

 

Jeff

[Tommy Murphy]

Hi Jeff

Is this of any use?

https://lists.riscv.org/g/tech-privileged/topic/79943096

The discussion here seems to have petered out (or maybe concluded?) back in January 2021.

Searching further suggests that patches for (this version of?) RNMI were submitted to certain development/debug/simulation tool projects around April 2021.

Regards

Tommy

---

From: Jeff Scott <jeff....@nxp.com>
Sent: Thursday, October 28, 2021 3:37:14 PM

[Krste Asanovic]

We’re working on an updated more complete spec, hopefully to come out soon.

Krste

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/LO2P265MB4776F1BB1DE276BC533D3ADEF9869%40LO2P265MB4776.GBRP265.PROD.OUTLOOK.COM.

[Jeff Scott]

Thanks Tommy!  That was very helpful and is along the same lines I would take if doing this as a custom extension.

 

Krste, where are you putting rnmie bit?  Any chance I could get an early draft of the spec?  I’d like to align my implementation with the standard as much as possible.

 

Subscribing to tech-privileged now…