|
Dear architect， Can the M interrupt such as MTI be delegated to S mode ?
|
|
|
Priv section 3.1.8 allows for but does not require that MTI be delegatable. So in that sense the answer is yes. But delegating MTI should generally be an unusual thing and some or many implementations may not allow it to be delegatable.
Greg
Dear architect， Can the M interrupt such as MTI be delegated to S mode ?
|
|
|
Allen Baum
As far as I can tell, an implementation may, but is not required to, disallow it. If it is delegated, it shows up in the SIP. STIP bit But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
Dear architect， Can the M interrupt such as MTI be delegated to S mode ?
|
|
|
Scott Johnson
Comments embedded: On Dec 7, 2022, at 11:39 AM, Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1] If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to access the interrupt controller too, removing any need for an ECALL.
|
|
|
Allen Baum
I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode. That's why the interrupt pending bit shows up in bit 5 if delegated, but bit 7 if not.
MTIP is NOT driven by the PLIC; the PLIC only sends external interrupts, not timer interrupts (which correspond to bits xstatus[11..9]
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would enable Smode to write it, but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future.
Comments embedded:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1] If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to access the interrupt controller too, removing any need for an ECALL.
|
|
|
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would enable Smode to write it, but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future.
mtimecmp is not a CSR: "Platforms provide a 64-bit memory-mapped machine-mode timer compare register (mtimecmp)." It's also not defined to be M-only, though I would assume that M-mode software would normally use PMP to make it off-limits to other modes.
Thanks,
-Paul
|
|
|
Allen,
I don’t agree that a machine mode interrupt (MEI, MSI, MTI) delegated to supervisor mode shows up in SIP as the supervisor version (SEI, SSI, STI) and not the machine version (MEI, MSI, MTI).
From the spec “The
sip and
sie registers are subsets of the
mip and
mie registers. Reading any implemented
field, or writing any writable field, of
sip/sie
effects a read or write of the homonymous field
of
mip/mie.”
This discussion has come up before by the way. If we updated the spec as a result of the last discussion, this wouldn’t have come up again.
Jeff
toggle quoted message
Show quoted text
From: tech-privileged@... <tech-privileged@...>
On Behalf Of Allen Baum via lists.riscv.org
Sent: Wednesday, December 7, 2022 3:52 PM
To: Scott Johnson <scott.johnson@...>
Cc: Oscar Jupp <jupposcar@...>; tech-privileged@...; tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] Question about mideleg
Caution: EXT Email
I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode.
That's why the interrupt pending bit shows up in bit 5 if delegated, but bit 7 if not.
MTIP is NOT driven by the PLIC; the PLIC only sends external interrupts, not timer interrupts (which correspond to bits xstatus[11..9]
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would enable Smode to write it,
but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future.
Comments embedded:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1]
If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to access the interrupt controller too, removing any need for
an ECALL.
|
|
|
Scott Johnson
The question was about delegating MTIP, not STIP. I don’t know why you’re talking about STIP at all; that’s a different interrupt entirely. MTIP vs STIP has nothing to do with what privilege mode will handle the interrupt. That is determined entirely by mideleg, not by the name of the interrupt.
MTIP is invisible to S-mode because mideleg[7] is 0. Just like STIP is invisible to S-mode if mideleg[5] is 0.
I don’t know what xstatus refers to — is that mstatus/sstatus? Bits 11:9 of those have nothing to do with interrupts?
My mistake about PLIC; I meant that MTIP is driven by CLINT. The MTIMECMP CSR is not accessed through CSRRW instructions. It is memory-mapped. An implementation could conceivably allow PMP and/or PMA settings that would allow S-mode access to this CSR. Like you say, not a good idea. Just like delegating MTIP to S-mode is probably not a good idea.
But all of this is academic and is just speculation about how it would work if mideleg[7] was writable, which I don’t think any reasonable implementation would support.
On Dec 7, 2022, at 3:52 PM, Allen Baum <allen.baum@...> wrote:
I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode. That's why the interrupt pending bit shows up in bit 5 if delegated, but bit 7 if not.
MTIP is NOT driven by the PLIC; the PLIC only sends external interrupts, not timer interrupts (which correspond to bits xstatus[11..9]
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would enable Smode to write it, but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future. Comments embedded:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1] If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to access the interrupt controller too, removing any need for an ECALL.
|
|
|
Also from the spec:
“Bits 3, 7, and 11 of sip and sie correspond to the machine-mode software, timer, and
external interrupts, respectively. Since
most platforms will choose not to make these interrupts
delegatable from M-mode to S-mode, they are shown as hardwired to 0 in Figures
4.6 and 4.7.”
I think the source of confusion is “most”.
Jeff
toggle quoted message
Show quoted text
From: tech-privileged@... <tech-privileged@...>
On Behalf Of Jeff Scott via lists.riscv.org
Sent: Wednesday, December 7, 2022 4:17 PM
To: allen.baum@...; Scott Johnson <scott.johnson@...>
Cc: Oscar Jupp <jupposcar@...>; tech-privileged@...; tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] Question about mideleg
Caution: EXT Email
Allen,
I don’t agree that a machine mode interrupt (MEI, MSI, MTI) delegated to supervisor mode shows up in SIP as the supervisor version (SEI, SSI, STI) and not the machine version (MEI, MSI, MTI).
From the spec “The
sip and
sie registers are subsets of the
mip and
mie registers. Reading any implemented
field, or writing any writable field, of
sip/sie
effects a read or write of the homonymous field
of
mip/mie.”
This discussion has come up before by the way. If we updated the spec as a result of the last discussion, this wouldn’t have come up again.
Jeff
Caution: EXT Email
I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode.
That's why the interrupt pending bit shows up in bit 5 if delegated, but bit 7 if not.
MTIP is NOT driven by the PLIC; the PLIC only sends external interrupts, not timer interrupts (which correspond to bits xstatus[11..9]
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would enable Smode to write it,
but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future.
Comments embedded:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1]
If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to access the interrupt controller too, removing any need for
an ECALL.
|
|
|
Allen Baum
The non-normative note below figure 4.6 and 4.7 say that –
but they don’t show that!
There is (currently) only one timer signal coming in. If MTIP is delegated without STIP being set (Mmode can set it), then I'm not quite sure what happens; no trap is ever taken, I suspect - it is equivalent to disabling timer interrupts completely, since both SIP and SIE are required to be set for the trap to occur, and they won't occur in M-mode because the delegation bit is set.
So, it has to show up in SIP if a trap is taken f MTIP delegated (it just doesn't automatically show up) Spec section 3.1.8 says "if the supervisor timer interrupt (STI) is delegated to S-mode by setting mideleg[5], STIs
will not be taken when executing in M-mode."
My reading of the spec is that both medeleg.stip] and xip.stip must be set for the trap to occur to an smode handler. As Paul points out, delegating may not be advised, because the resources to clear the interrupt may not be available to Smode (which means an ECALL to Mmode to clear it) and if it is available to Smode, then you have a security issue, because Smode can effectively ensure timer interrupts will never occur again. That problem will go away if the STIMER extension is ratified, I think.
Also from the spec:
“Bits 3, 7, and 11 of sip and sie correspond to the machine-mode software, timer, and
external interrupts, respectively. Since
most platforms will choose not to make these interrupts
delegatable from M-mode to S-mode, they are shown as hardwired to 0 in Figures
4.6 and 4.7.”
I think the source of confusion is “most”.
Jeff
Caution: EXT Email
Allen,
I don’t agree that a machine mode interrupt (MEI, MSI, MTI) delegated to supervisor mode shows up in SIP as the supervisor version (SEI, SSI, STI) and not the machine version (MEI, MSI, MTI).
From the spec “The
sip and
sie registers are subsets of the
mip and
mie registers. Reading any implemented
field, or writing any writable field, of
sip/sie
effects a read or write of the homonymous field
of
mip/mie.”
This discussion has come up before by the way. If we updated the spec as a result of the last discussion, this wouldn’t have come up again.
Jeff
Caution: EXT Email
I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode.
That's why the interrupt pending bit shows up in bit 5 if delegated, but bit 7 if not.
MTIP is NOT driven by the PLIC; the PLIC only sends external interrupts, not timer interrupts (which correspond to bits xstatus[11..9]
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would enable Smode to write it,
but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future.
Comments embedded:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1]
If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to access the interrupt controller too, removing any need for
an ECALL.
|
|
|
> That problem will go away if the STIMER extension is ratified, I think. Do you mean Sstc (which introduces stimecmp and vstimecmp)? That was ratified last year (though the spec looks like it still says "frozen").
-Paul
The non-normative note below figure 4.6 and 4.7 say that –
but they don’t show that!
There is (currently) only one timer signal coming in. If MTIP is delegated without STIP being set (Mmode can set it), then I'm not quite sure what happens; no trap is ever taken, I suspect - it is equivalent to disabling timer interrupts completely, since both SIP and SIE are required to be set for the trap to occur, and they won't occur in M-mode because the delegation bit is set.
So, it has to show up in SIP if a trap is taken f MTIP delegated (it just doesn't automatically show up) Spec section 3.1.8 says "if the supervisor timer interrupt (STI) is delegated to S-mode by setting mideleg[5], STIs
will not be taken when executing in M-mode."
My reading of the spec is that both medeleg.stip] and xip.stip must be set for the trap to occur to an smode handler. As Paul points out, delegating may not be advised, because the resources to clear the interrupt may not be available to Smode (which means an ECALL to Mmode to clear it) and if it is available to Smode, then you have a security issue, because Smode can effectively ensure timer interrupts will never occur again. That problem will go away if the STIMER extension is ratified, I think.
Also from the spec:
“Bits 3, 7, and 11 of sip and sie correspond to the machine-mode software, timer, and
external interrupts, respectively. Since
most platforms will choose not to make these interrupts
delegatable from M-mode to S-mode, they are shown as hardwired to 0 in Figures
4.6 and 4.7.”
I think the source of confusion is “most”.
Jeff
Caution: EXT Email
Allen,
I don’t agree that a machine mode interrupt (MEI, MSI, MTI) delegated to supervisor mode shows up in SIP as the supervisor version (SEI, SSI, STI) and not the machine version (MEI, MSI, MTI).
From the spec “The
sip and
sie registers are subsets of the
mip and
mie registers. Reading any implemented
field, or writing any writable field, of
sip/sie
effects a read or write of the homonymous field
of
mip/mie.”
This discussion has come up before by the way. If we updated the spec as a result of the last discussion, this wouldn’t have come up again.
Jeff
Caution: EXT Email
I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode.
That's why the interrupt pending bit shows up in bit 5 if delegated, but bit 7 if not.
MTIP is NOT driven by the PLIC; the PLIC only sends external interrupts, not timer interrupts (which correspond to bits xstatus[11..9]
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would enable Smode to write it,
but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future.
Comments embedded:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1]
If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to access the interrupt controller too, removing any need for
an ECALL.
|
|
|
Allen,
If you delegate mtip, and you get a mtip, bit 7 in sip will be set, as well as bit 7 in mip.
I agree that the non-normative note does not match what is shown in 4.6. This has been discussed before.
Jeff
toggle quoted message
Show quoted text
From: Allen Baum <allen.baum@...>
Sent: Wednesday, December 7, 2022 5:07 PM
To: Jeff Scott <jeff.scott@...>
Cc: Scott Johnson <scott.johnson@...>; Oscar Jupp <jupposcar@...>; tech-privileged@...; tech-privileged@...
Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Question about mideleg
Caution: EXT Email
The non-normative note below figure 4.6 and 4.7 say that – but they don’t show that!
There is (currently) only one timer signal coming in.
If MTIP is delegated without STIP being set (Mmode can set it), then I'm not quite sure what happens; no trap is ever taken, I suspect - it is equivalent to disabling timer interrupts completely,
since both SIP and SIE are required to be set for the trap to occur, and they won't occur in M-mode because the delegation bit is set.
So, it has to show up in SIP if a trap is taken f MTIP delegated (it just doesn't automatically show up)
"if the supervisor timer interrupt (STI) is delegated to S-mode by setting
mideleg[5], STIs will not be taken when executing in M-mode."
My reading of the spec is that both medeleg.stip] and xip.stip must be set for the trap to occur to an smode handler.
As Paul points out, delegating may not be advised, because the resources to clear the interrupt may not be available to Smode (which means an ECALL to Mmode to clear it)
and if it is available to Smode, then you have a security issue, because Smode can effectively ensure timer interrupts will never occur again.
That problem will go away if the STIMER extension is ratified, I think.
Also from the spec:
“Bits 3, 7, and 11 of sip and sie correspond to the machine-mode software, timer, and
external interrupts, respectively. Since
most platforms will choose not to make these interrupts
delegatable from M-mode to S-mode, they are shown as hardwired to 0 in Figures
4.6 and 4.7.”
I think the source of confusion is “most”.
Jeff
Caution: EXT Email
Allen,
I don’t agree that a machine mode interrupt (MEI, MSI, MTI) delegated to supervisor mode shows up in SIP as the supervisor version (SEI, SSI, STI) and not the machine version (MEI,
MSI, MTI).
From the spec “The
sip and
sie registers are subsets of the
mip and
mie registers. Reading any implemented
field, or writing any writable field, of
sip/sie
effects a read or write of the homonymous field
of
mip/mie.”
This discussion has come up before by the way. If we updated the spec as a result of the last discussion, this wouldn’t have come up again.
Jeff
Caution: EXT Email
I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode.
That's why the interrupt pending bit shows up in bit 5 if delegated, but bit 7 if not.
MTIP is NOT driven by the PLIC; the PLIC only sends external interrupts, not timer interrupts (which correspond to bits xstatus[11..9]
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would
enable Smode to write it,
but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future.
Comments embedded:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1]
If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up
in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to
access the interrupt controller too, removing any need for an ECALL.
|
|
|
Allen Baum
Hmm, I misread that, and re-reading: this implies that sip.MTIP is not necessarily 0. I thought it had to be zero because everything Mmode related is normally hidden from S-mode for virtualization reasons. This puzzles me
It also puzzles me that an interrupt could set two different bits in xIP in hardware.
Allen,
If you delegate mtip, and you get a mtip, bit 7 in sip will be set, as well as bit 7 in mip.
I agree that the non-normative note does not match what is shown in 4.6. This has been discussed before.
Jeff
Caution: EXT Email
The non-normative note below figure 4.6 and 4.7 say that – but they don’t show that!
There is (currently) only one timer signal coming in.
If MTIP is delegated without STIP being set (Mmode can set it), then I'm not quite sure what happens; no trap is ever taken, I suspect - it is equivalent to disabling timer interrupts completely,
since both SIP and SIE are required to be set for the trap to occur, and they won't occur in M-mode because the delegation bit is set.
So, it has to show up in SIP if a trap is taken f MTIP delegated (it just doesn't automatically show up)
"if the supervisor timer interrupt (STI) is delegated to S-mode by setting
mideleg[5], STIs will not be taken when executing in M-mode."
My reading of the spec is that both medeleg.stip] and xip.stip must be set for the trap to occur to an smode handler.
As Paul points out, delegating may not be advised, because the resources to clear the interrupt may not be available to Smode (which means an ECALL to Mmode to clear it)
and if it is available to Smode, then you have a security issue, because Smode can effectively ensure timer interrupts will never occur again.
That problem will go away if the STIMER extension is ratified, I think.
Also from the spec:
“Bits 3, 7, and 11 of sip and sie correspond to the machine-mode software, timer, and
external interrupts, respectively. Since
most platforms will choose not to make these interrupts
delegatable from M-mode to S-mode, they are shown as hardwired to 0 in Figures
4.6 and 4.7.”
I think the source of confusion is “most”.
Jeff
Caution: EXT Email
Allen,
I don’t agree that a machine mode interrupt (MEI, MSI, MTI) delegated to supervisor mode shows up in SIP as the supervisor version (SEI, SSI, STI) and not the machine version (MEI,
MSI, MTI).
From the spec “The
sip and
sie registers are subsets of the
mip and
mie registers. Reading any implemented
field, or writing any writable field, of
sip/sie
effects a read or write of the homonymous field
of
mip/mie.”
This discussion has come up before by the way. If we updated the spec as a result of the last discussion, this wouldn’t have come up again.
Jeff
Caution: EXT Email
I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode.
That's why the interrupt pending bit shows up in bit 5 if delegated, but bit 7 if not.
MTIP is NOT driven by the PLIC; the PLIC only sends external interrupts, not timer interrupts (which correspond to bits xstatus[11..9]
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would
enable Smode to write it,
but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future.
Comments embedded:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1]
If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up
in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to
access the interrupt controller too, removing any need for an ECALL.
|
|
|
Scott Johnson
On Dec 7, 2022, at 7:35 PM, Allen Baum <allen.baum@...> wrote:
Hmm, I misread that, and re-reading: this implies that sip.MTIP is not necessarily 0. I thought it had to be zero because everything Mmode related is normally hidden from S-mode for virtualization reasons. This puzzles me
You seem to be confused by the names of the two interrupts MTI and STI. Think of them not as Machine/Supervisor but as Timer Interrupts A and B.
One of the two is traditionally delegated to S-mode via mideleg. But not necessarily.
If mideleg[5] is 0 then STIP is M-mode and hidden from S-mode. If mideleg[5] is 1 then STIP is S-mode and visible to both M-mode and S-mode.
If mideleg[7] is 0 then MTIP is M-mode and hidden from S-mode. If mideleg[7] is 1 then MTIP is S-mode and visible to both M-mode and S-mode.
It also puzzles me that an interrupt could set two different bits in xIP in hardware.
That doesn’t happen.
|
|
|
Agree Scott. There really is no sip register. sip is mip & mideleg.
Jeff
toggle quoted message
Show quoted text
From: tech-privileged@... <tech-privileged@...>
On Behalf Of Scott Johnson via lists.riscv.org
Sent: Wednesday, December 7, 2022 7:51 PM
To: Allen Baum <allen.baum@...>
Cc: tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] Question about mideleg
Caution: EXT Email
Hmm, I misread that, and re-reading: this implies that sip.MTIP is not necessarily 0.
I thought it had to be zero because everything Mmode related is normally hidden from S-mode for virtualization reasons.
You seem to be confused by the names of the two interrupts MTI and STI. Think of them not as Machine/Supervisor but as Timer Interrupts A and B.
One of the two is traditionally delegated to S-mode via mideleg. But not necessarily.
If mideleg[5] is 0 then STIP is M-mode and hidden from S-mode. If mideleg[5] is 1 then STIP is S-mode and visible to both M-mode and S-mode.
If mideleg[7] is 0 then MTIP is M-mode and hidden from S-mode. If mideleg[7] is 1 then MTIP is S-mode and visible to both M-mode and S-mode.
It also puzzles me that an interrupt could set two different bits in xIP in hardware.
That doesn’t happen.
|
|
|
