Delegation of machine mode interrupts

[Sourav Roy]

Can machine mode interrupts (MEI,MTI,MSI) be delegated to supervisor level ? The spec clearly says that machine mode exceptions like machine mode ecall cannot be delegated (so MEDELEG[11] = 0) and that's natural because the code is executing in machine mode at the time of exception. But it does not clearly say anything about MIDELEG machine bits (MEI,MTI,MSI). If these machine interrupts can be delegated, the spec says that they will be visible in the SIE, SIP registers -- but these registers don't have the MEI,MTI,MSI bits. I mean these bits are not accessible from the supervisor level handler which can only access SIE,SIP. Am I missing something ?

[Tommy Thorn]

I think you answered it yourself. They aren't visible in SIP because they can't be delegated. IOW, the corresponding bits in MIDELEG are hardwired zero.

Tommy

On Thu, Jun 11, 2020 at 10:19 PM Sourav Roy <sourav...@gmail.com> wrote:

Can machine mode interrupts (MEI,MTI,MSI) be delegated to supervisor level ? The spec clearly says that machine mode exceptions like machine mode ecall cannot be delegated (so MEDELEG[11] = 0) and that's natural because the code is executing in machine mode at the time of exception. But it does not clearly say anything about MIDELEG machine bits (MEI,MTI,MSI). If these machine interrupts can be delegated, the spec says that they will be visible in the SIE, SIP registers -- but these registers don't have the MEI,MTI,MSI bits. I mean these bits are not accessible from the supervisor level handler which can only access SIE,SIP. Am I missing something ?

--
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/6ec5c5a1-591e-4210-bb26-db116fb7c9bfo%40groups.riscv.org.

[Jeff Scott]

Per 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 marked WPRI in Figures 4.4 and 4.5.”

 

Why say “most” and then not show them in the CSR figure?

 

“most” sounds like they “can” be delegated.

 

Jeff

 

From: Tommy Thorn <tommy...@esperantotech.com>
Sent: Friday, June 12, 2020 1:41 AM
To: Sourav Roy <sourav...@gmail.com>
Cc: RISC-V ISA Dev <isa...@groups.riscv.org>; Sourav Roy <soura...@nxp.com>
Subject: [EXT] Re: [isa-dev] Delegation of machine mode interrupts

 

Caution: EXT Email

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPZiS_5Tf5L8LH0_r4ruroFPRGrr6o_NX60FVcT%2BETFKJNUeBw%40mail.gmail.com.

[Richard Bohn]

This issue has been brought up before:

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

---

From: Jeff Scott <jeff....@nxp.com>
Sent: Friday, June 12, 2020 9:33 AM
To: Tommy Thorn <tommy...@esperantotech.com>; Sourav Roy <sourav...@gmail.com>

Cc: RISC-V ISA Dev <isa...@groups.riscv.org>; Sourav Roy <soura...@nxp.com>

Subject: RE: [EXT] Re: [isa-dev] Delegation of machine mode interrupts

 

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/VE1PR04MB643109D24D14113FFB7ECA3E8D810%40VE1PR04MB6431.eurprd04.prod.outlook.com.

[Jeff Scott]

Thanks.  It doesn’t mention the part I quoted below.  The part I quoted below should be removed from the spec IF the intent is not to allow that.  The spec should clearly state/list what exceptions and interrupts are delegateable.  Since it’s not listed in the spec, can we at least have it listed on this email list?  If it’s implementation dependent, let’s clearly state that.

 

Jeff

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/BY5PR20MB3234CBFA3D4381038812A1DE97810%40BY5PR20MB3234.namprd20.prod.outlook.com.

[Richard Bohn]

The part you quoted is the commit that Andrew made to close that issue:

https://github.com/riscv/riscv-isa-manual/commit/ec2fe254b46850f9de05c04e50b8dabac65e3868

I don't disagree that it is an unsatisfactory resolution. If the spec allows for delegation, then the bits should exist in the diagram (perhaps with a footnote that this is not common to address Andrew's confusion concern). Or if the spec doesn't allow for delegation then the bits don't exist.

---

From: Jeff Scott <jeff....@nxp.com>
Sent: Friday, June 12, 2020 9:52 AM
To: Richard Bohn <richar...@seagate.com>; Tommy Thorn <tommy...@esperantotech.com>; Sourav Roy <sourav...@gmail.com>
Cc: Sourav Roy <soura...@nxp.com>; isa...@groups.riscv.org <isa...@groups.riscv.org>

[Jeff Scott]

These figures should be completely filled out to show what is delegateable:

 

 

With 0s on ones that cannot be delegated.

 

Jeff

[Allen Baum]

My pedantic hat says you are correct; 

I wonder how the formal model models this? 

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/VE1PR04MB643119B39292873A66A07A1E8D810%40VE1PR04MB6431.eurprd04.prod.outlook.com.

[Sourav Roy]

Another point to consider is, do we want to provide hardware hooks to delegate interrupts to a lower privilege level than what it is meant for ? It seems counter-intuitive to the concept of privilege levels. I think its more secure and clean to delegate to the desired level (and down / higher levels).

[Jeff Scott]

Andrew, could you give us some guidance here?  Would like to explicitly know what is delegateable.  If some are implementation dependent, please indicate.

 

Jeff

 

From: Sourav Roy <soura...@nxp.com>
Sent: Saturday, June 13, 2020 7:21 AM
To: Jeff Scott <jeff....@nxp.com>; Richard Bohn <richar...@seagate.com>; Tommy Thorn <tommy...@esperantotech.com>; Sourav Roy <sourav...@gmail.com>
Cc: isa...@groups.riscv.org
Subject: RE: [EXT] Re: [isa-dev] Delegation of machine mode interrupts

 

Another point to consider is, do we want to provide hardware hooks to delegate interrupts to a lower privilege level than what it is meant for ? It seems counter-intuitive to the concept of privilege levels. I think its more secure and clean to delegate to the desired level (and higher levels).

 

Thanks,

Sourav

[Andrew Waterman]

I think the current mideleg spec makes it clear that implementations are free to support delegation of any interrupt, even though some implementations might not support delegation of all interrupts.  (This is in contrast to Tommy's once-correct assertion that MEI, MTI, and MSI aren't delegable.  People requested that constraint be relaxed.)

The bug here is in the supervisor interrupts table.  I find Richard's proposed solution of a footnote satisfactory.  If someone prepares a pull request to add the interrupts to the supervisor table, along with proposed text for the footnote, I'll take it from there.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/VE1PR04MB643139B4824A4DD92B4F35328D950%40VE1PR04MB6431.eurprd04.prod.outlook.com.

[Jeff Scott]

Thanks, this is clear.

 

Jeff