Master, Supervisor, and User Interrupt question
385 views
Skip to first unread message
Samuel Falvo II
Aug 2, 2018, 11:24:23 AM8/2/18
to RISC-V ISA Dev
I chose to ask this question on ISA-Dev because this relates to my
understanding of how interrupts work based on the current Privileged
Spec version 1.10, even though the topic has some cross-over with
hw-dev.
For several revisions of the priv-spec, I've always been baffled by
the MIP/MIE registers, and how they have four bits of interrupt
pending/enable states per interrupt source. What follows is my
current understanding of how things can or should work. Can someone
double-check to make sure I'm not being daft?
Let's focus just on external interrupts for the time being.
A RISC-V implementation may choose to expose up to three external
interrupt pins to an external circuit: MIRQ, SIRQ, and UIRQ. Each
external interrupt input is intended to trigger an appropriate,
asynchronously dispatched handler running at their corresponding
privilege level.
If UIRQ is asserted, AND if the processor is presently running in
user-mode, AND if MIE.UEIE is set, then a user-mode trap will take
place to handle the external user-mode interrupt by dispatching to
UTVEC, setting UCAUSE, and UEPC appropriately. If MIE.UEIE is not
set, or if the processor is running at a higher privilege level, then
the interrupt will remain queued (at least, as long as UIRQ remains
asserted).
If SIRQ is asserted, AND if the processor is presently running in
either user-mode or supervisor-mode, AND if MIE.SEIE is set, AND if
SIDELEG.SEI is zero, then a supervisor-mode trap will take place to
handle the external supervisor-level interrupt by dispatching to
STVEC, setting SCAUSE and SEPC, etc. If SIDELEG.SEI is set, then
it'll be handled as a user-mode interrupt, as above, even if U-mode
was running its own trap handler at the time (note: make U-mode trap
handlers re-entrant to ensure state corruption doesn't occur due to
this case!). As with UIRQ handling above, if any of the other
conditions is not the case, then the supervisor interrupt will be
delayed until it can be properly handled.
If MIRQ is asserted, AND if the processor is running in machine-mode,
supervisor-mode, or user-mode, AND if MIE.MEIE bit is set, AND
MIDELEG.MEI is zero, then a machine-mode trap takes place via MTVEC,
setting MCAUSE and MEPC, etc. If MIDELEG.MEI is set but SIDELEG.SEI
is zero, then the trap will be handled as a supervisor-level
interrupt. If both are 1, then as a user-level interrupt. Remember
to make all appropriate trap handlers re-entrant if delegation is to
be supported. If all other conditions are not present, then as usual,
the M-mode interrupt will be delayed until it can be serviced.
Is my understanding correct? Thanks!
--
Samuel A. Falvo II
understanding of how interrupts work based on the current Privileged
Spec version 1.10, even though the topic has some cross-over with
hw-dev.
For several revisions of the priv-spec, I've always been baffled by
the MIP/MIE registers, and how they have four bits of interrupt
pending/enable states per interrupt source. What follows is my
current understanding of how things can or should work. Can someone
double-check to make sure I'm not being daft?
Let's focus just on external interrupts for the time being.
A RISC-V implementation may choose to expose up to three external
interrupt pins to an external circuit: MIRQ, SIRQ, and UIRQ. Each
external interrupt input is intended to trigger an appropriate,
asynchronously dispatched handler running at their corresponding
privilege level.
If UIRQ is asserted, AND if the processor is presently running in
user-mode, AND if MIE.UEIE is set, then a user-mode trap will take
place to handle the external user-mode interrupt by dispatching to
UTVEC, setting UCAUSE, and UEPC appropriately. If MIE.UEIE is not
set, or if the processor is running at a higher privilege level, then
the interrupt will remain queued (at least, as long as UIRQ remains
asserted).
If SIRQ is asserted, AND if the processor is presently running in
either user-mode or supervisor-mode, AND if MIE.SEIE is set, AND if
SIDELEG.SEI is zero, then a supervisor-mode trap will take place to
handle the external supervisor-level interrupt by dispatching to
STVEC, setting SCAUSE and SEPC, etc. If SIDELEG.SEI is set, then
it'll be handled as a user-mode interrupt, as above, even if U-mode
was running its own trap handler at the time (note: make U-mode trap
handlers re-entrant to ensure state corruption doesn't occur due to
this case!). As with UIRQ handling above, if any of the other
conditions is not the case, then the supervisor interrupt will be
delayed until it can be properly handled.
If MIRQ is asserted, AND if the processor is running in machine-mode,
supervisor-mode, or user-mode, AND if MIE.MEIE bit is set, AND
MIDELEG.MEI is zero, then a machine-mode trap takes place via MTVEC,
setting MCAUSE and MEPC, etc. If MIDELEG.MEI is set but SIDELEG.SEI
is zero, then the trap will be handled as a supervisor-level
interrupt. If both are 1, then as a user-level interrupt. Remember
to make all appropriate trap handlers re-entrant if delegation is to
be supported. If all other conditions are not present, then as usual,
the M-mode interrupt will be delayed until it can be serviced.
Is my understanding correct? Thanks!
--
Samuel A. Falvo II
Luke Kenneth Casson Leighton
Aug 2, 2018, 12:36:02 PM8/2/18
to Samuel Falvo II, RISC-V ISA Dev
On Thursday, August 2, 2018, Samuel Falvo II <sam....@gmail.com> wrote:
...
...
Let's focus just on external interrupts for the time being.
If UIRQ is asserted, AND if the processor is presently running in
user-mode, AND if
...
...
This looks like it would be reeeally good to have in rs nikhil's formal spec, if it isnt already. Can i possibly float the idea of writing it in that format, samuel?
--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Pierre G.
Aug 2, 2018, 12:46:54 PM8/2/18
to Luke Kenneth Casson Leighton, Samuel Falvo II, RISC-V ISA Dev
The way Samuel is describing the interrupt is exhaustive and, in my view, helps to better understand the overall dynamic - may be we could use uml dynamic sequence diagram.
I would add that each state of Riscv has a global enable for interrupt located in the register m,s,ustatus. So there is a two stage enables : one global per state then one bit per types of interrupt (external, timer, software). Last point : it is machine mode instead of master mode.
--
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/CAPweEDx-rdZn2UEDxS_LfDdJrvfQqcPZbDwLQKmG9dWGxfyNKw%40mail.gmail.com.
Samuel Falvo II
Aug 2, 2018, 12:50:37 PM8/2/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev
On Thu, Aug 2, 2018 at 9:36 AM Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
> This looks like it would be reeeally good to have in rs nikhil's formal spec, if it isnt already. Can i possibly float the idea of writing it in that format, samuel?
Yes, that's fine. The way I wrote the description was inspired by
<lk...@lkcl.net> wrote:
> This looks like it would be reeeally good to have in rs nikhil's formal spec, if it isnt already. Can i possibly float the idea of writing it in that format, samuel?
Abstract State Machines, actually, but just written out informally as
a paragraph to preserve vertical space.
Samuel Falvo II
Aug 2, 2018, 12:52:30 PM8/2/18
to Pierre G., Luke Kenneth Casson Leighton, RISC-V ISA Dev
On Thu, Aug 2, 2018 at 9:46 AM Pierre G. <pig...@gmail.com> wrote:
> I would add that each state of Riscv has a global enable for interrupt located in the register m,s,ustatus. So there is a two stage enables : one global per state then one bit per types of interrupt (external, timer, software). Last point : it is machine mode instead of master mode.
Since SSTATUS and USTATUS are views onto MSTATUS, I only concerned
> I would add that each state of Riscv has a global enable for interrupt located in the register m,s,ustatus. So there is a two stage enables : one global per state then one bit per types of interrupt (external, timer, software). Last point : it is machine mode instead of master mode.
myself with MSTATUS, since all relevant bits in MSTATUS will
automatically be reflected in SSTATUS and USTATUS as appropriate.
Regarding machine/master mode: Thanks; it's still much too early in
the morning for me.
Andrew Waterman
Aug 2, 2018, 3:01:47 PM8/2/18
to Samuel Falvo II, RISC-V ISA Dev
U, S, and M don't actually connote anything about privilege. UIRQ,
SIRQ, and MIRQ are three different interrupt lines on equal footing.
The prefix letters merely reflect the intended use case. So only one
version of this description is necessary. I'll try to rewrite a
version with a few corrections. It's easiest to break it down by the
delegation settings:
If UIRQ is asserted and MIE.UEIE is set, and if MIDELEG.UEI=0, and the
processor is running in M-mode with MSTATUS.MIE=1, or running in
U-mode or S-mode regardless of MSTATUS.MIE, then the trap will be
taken into M-mode.
If UIRQ is asserted and MIE.UEIE is set, and if MIDELEG.UEI=1 and
SIDELEG.UEI=0, and the processor is running in S-mode with
MSTATUS.SIE=1, or running in U-mode regardless of MSTATUS.SIE, then
the trap will be taken into S-mode. The interrupt will never be taken
when running in M-mode.
If UIRQ is asserted and MIE.UEIE is set, and if MIDELEG.UEI=1 and
SIDELEG.UEI=1, and the processor is running in U-mode with
MSTATUS.UIE=1, then the trap will be taken into U-mode. The interrupt
will never be taken when running in M-mode or S-mode.
>
> --
> 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+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/CAEz%3Dsonhe-9eTZTyuSp7o1dAzB4E4eids2R-5pquiU%3DU-E_Vng%40mail.gmail.com.
> 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/.
Allen Baum
Aug 2, 2018, 6:25:42 PM8/2/18
to Andrew Waterman, Samuel Falvo II, RISC-V ISA Dev
I drew a diagram that tried to describe the entire flow which should be in the slides I presented at the Barcelona workshop for those who can understand diagrams between than paragraphs.
I will reiterate what Andrew said: the M/S/U are arbitrary names; call them X/Y/Z.
Interrupts sources can be configured to generate any XYZ interrupt, and it could result in an interrupt that could occur in any mode (assuming the mode exists and interrupts are allowed, of course). There are constrains: you can't interrupt to a mode with less privilege than the one that is being interrupted (so the interrupt must be pended).
> 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%3Dsonhe-9eTZTyuSp7o1dAzB4E4eids2R-5pquiU%3DU-E_Vng%40mail.gmail.com.
--
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/CA%2B%2B6G0DmCABOe-aRRB4odsCiEGa3wBJdcv1oaqt2CE9s836_1w%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages