Why MPIE ?

[Pierre G.]

Hello All,

I have a naive question : why do we need MPIE ?

I understand how it works : when an interrupt is taken, MPIE captures the value of MIE, and at the end on the interrupt routine, MRET will copy back MPIE within MIE.

But, in anycase MPIE is necessarily equals to 1 :

- if an interrupt is taken, this means that MIE was enabled.

- at the time the interrupt occurs, MIE is copied into MPIE; so is 1.

- MIE is written to 0

After the first interrupt will be serviced (execution of MRET), MPIE still holds 1, and MIE is restored using MPIE=1.

I understand the role of SPIE & UPIE because S&U mode can be interrupted to go into machine mode, but I do not understand the need of MIPE since machine mode cannot be interrupted and switch to lower priority mode.

Thanks in advance for your feedback.

[Krste Asanovic]

Synchronous exceptions

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 post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3c3e4c6f-1905-4ae4-b5b1-b567c1f9a635%40groups.riscv.org.

[Samuel Falvo II]

M-mode actually can be interrupted by another M-mode interrupt source.
This can come from another hart running in M-mode and making an
inter-processor interrupt, OR, from external hardware interrupting
M-mode-only cores. You're right that M-mode cannot be "trapped" to a
lower privilege level; however, it can trap to its own privilege level
(since there is nothing defined to be higher privilege level than
M-mode). In this scenario, it's like a Z80 or 6502 taking an
interrupt, where the CPU runs effectively in the same privilege level
(since there are *no* defined privilege levels at all on these CPUs)
regardless if its running production code or interrupt service code.

> --
> 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 post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3c3e4c6f-1905-4ae4-b5b1-b567c1f9a635%40groups.riscv.org.

--
Samuel A. Falvo II

[Allen Baum]

Obviously, M-mode only implementations are allowed, so you need to be able to take interrupts from m-mode to m-mode.

When you first enter M-mode, interrupts are disabled, and you need to explicitly save state and reenable interrupts in order to take another interrupt (unless M-mode knows there is no state to save, but that only works once...). 

Taking exceptions (synchronous exceptions) is nastier - your handler M-mode code should be written so that it doesn't take an exception, or at least not before its had time to save a few CSRs somewhere (e.g. saving the few csrs better not trao!). Primarily, that means access to the physical address of the handler should guaranteed, and access to the save area should be guaranteed.

Having said that, it is still the case that an NMI could come in -  that's basically fatal in this scenario, and should be confined to HW error conditions that are fatal anyway.

Getting back to the original question: the reason you need MPIE is to prevent and allow reentrance.  

> email to isa-dev+unsubscribe@groups.riscv.org.

> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3c3e4c6f-1905-4ae4-b5b1-b567c1f9a635%40groups.riscv.org.

--
Samuel A. Falvo II

--
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+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

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

[Samuel Falvo II]

On Mon, Jul 16, 2018 at 12:30 PM, Allen Baum
<allen...@esperantotech.com> wrote:
> Obviously, M-mode only implementations are allowed, so you need to be able
> to take interrupts from m-mode to m-mode.

Even with other modes, it's still potentially useful.

> When you first enter M-mode, interrupts are disabled, and you need to
> explicitly save state and reenable interrupts in order to take another
> interrupt (unless M-mode knows there is no state to save, but that only
> works once...).

Of course.

> Taking exceptions (synchronous exceptions) is nastier - your handler M-mode

This isn't all that nasty to me. This is just plain common sense.

> Getting back to the original question: the reason you need MPIE is to
> prevent and allow reentrance.

Which everything I wrote directly implied (in fact, is impossible without it).

[Jacob Bachmeyer]

Allen Baum wrote:
> Taking exceptions (synchronous exceptions) is nastier - your handler
> M-mode code should be written so that it doesn't take an exception, or
> at least not before its had time to save a few CSRs somewhere (e.g.
> saving the few csrs better not trao!). Primarily, that means access to
> the physical address of the handler should guaranteed, and access to
> the save area should be guaranteed.

This was hashed out previously in the "nested trap" discussions: *all*
trap handlers must have a context-save area that can be accessed without
incurring a horizontal trap. This issue also hits the supervisor. It
is more than just the CSRs: the entire general register file must be saved.

> Having said that, it is still the case that an NMI could come in -
> that's basically fatal in this scenario, and should be confined to HW
> error conditions that are fatal anyway.

Does this mean that MPIE in the NMI handler is effectively the
"recoverable NMI" flag? If MPIE is set when the NMI handler is entered,
nothing has been lost (since the monitor was prepared for an interrupt)
and the monitor can resume execution after handling the NMI, probably
after software-delegating the NMI to a "machine check" handler
previously registered by the supervisor using some to-be-defined SBI
call. If MPIE is clear when the NMI handler is entered, the NMI
occurred while entering the monitor trap handler and the resume point
has been destroyed; the only path forwards is to reset.

High-reliability system can avoid these problems by placing the monitor
entry point and context save areas in internal (multi-port) SRAM, with
extensive ECC on that SRAM and dedicated ECC scrubbing hardware with its
own SRAM port. (If *that* fails, the main registers probably cannot be
trusted to hold values either and the system will crash no matter what.)


-- Jacob

[Allen Baum]

Huh - maybe. Interesting thought. But, probably not. If NMI is reporting an uncorrectable error, the purpose of NMI is to contain the error, killing off anything that could have been affected by it as cleanly as possible, ad notifying the world what it is killing off. if  MPIE is clear, then you need to kill everything because you have no idea what has been lost in addition to what the error itself lost.

Yes, if you can ensure that your monitor only accesses resources that won't cause an uncorrectable error, you can avoid NMI during M-mode.

Not sure you can guarantee that, but you may be able to make it unlikely enough to satisfy uptime requirements.

[Richard Herveille]

NMI is typically triggered by an external hardware failure. The NMI handler is used to prevent further damage to the system.

How can you avoid NMIs in M-mode?

Richard 

Sent from my iPhone

--
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 post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

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

[Liviu Ionescu]

> On 17 Jul 2018, at 09:21, Richard Herveille <richard....@roalogic.com> wrote:
>
> NMI is typically triggered by an external hardware failure. The NMI handler is used to prevent further damage to the system.

Strictly speaking, NMI is Non-Maskable Interrupt, i.e. an interrupt that cannot be masked (its trap handler is called each time the interrupt is fired, regardless of any system status).

Although not typical, NMI can be also used in hard real-time applications as the fastest, highest priority interrupt, that can never be disabled.


Regards,

Liviu

[Cesar Eduardo Barros]

For some reason, this discussion has reminded me of the 80386 and
successors, in which one of the steps to enter protected mode from real
mode is to mask all interrupts including the NMI...

--
Cesar Eduardo Barros
ces...@cesarb.eti.br

[Allen Baum]

NMI is typically triggered by an external hardware failure. The NMI handler is used to prevent further damage to the system.

Any detected uncorrectable error could use NMI, not just external ones

(though whether an L1 write back error is considered external or internal is debatable). 

I was using it as a general Machine Check in the absence of an architected Machine Check. And, yes, exactly, it is used to avoid further damage by containing the error and killing off anything that might have been "infected" by the error. Sometimes you can tell, but when you can't, a reset back to a known good state is the only option.

-Allen

--
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 post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/d5d7017f-4a06-f33a-d41b-8e7954f1f9c6%40cesarb.eti.br.

--
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 post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/d5d7017f-4a06-f33a-d41b-8e7954f1f9c6%40cesarb.eti.br.

[Cesar Eduardo Barros]

Em 17-07-2018 10:54, Allen Baum escreveu:
>>>> NMI is typically triggered by an external hardware failure. The NMI
>>>> handler is used to prevent further damage to the system.
>
> Any detected uncorrectable error could use NMI, not just external ones
> (though whether an L1 write back error is considered external or
> internal is debatable).
>
> I was using it as a general Machine Check in the absence of an
> architected Machine Check. And, yes, exactly, it is used to avoid
> further damage by containing the error and killing off anything that
> might have been "infected" by the error. Sometimes you can tell, but
> when you can't, a reset back to a known good state is the only option.

What happens if the memory used by the NMI handler code itself is what
got an uncorrectable error?

[Allen Baum]

Power down and replace the memory?

That's a pretty serious scenario, since there had to be some.other fault to even get to the handler that just faults again.

That sounds like a hard failure, and software isn't going to be able to fix it.


-Allen