1. Messages
  2. Question about supervisor interrupt in M mode

Re: Question about supervisor interrupt in M mode

Jeff Scott
 

I agree this took me several readings of the spec to understand this.  Pseudo-code would have saved myself and others a lot of time.

 

Allen, thanks for taking the time to share this!

 

Can we add the final equation to the spec?  It will save time for first time readers of the spec as well as everyone’s time answering questions in this area.

 

Jeff

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Scott Johnson via lists.riscv.org
Sent: Wednesday, November 30, 2022 10:04 AM
To: Allen Baum <allen.baum@...>
Cc: Oscar Jupp <jupposcar@...>; tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode

 

Caution: EXT Email

I agree this part of the spec is hard to understand, and requires piecing together several diverse sources within the privileged spec.

 

I don’t think your clarifications below are quite correct. More inline:

 



On Nov 30, 2022, at 2:34 AM, Allen Baum <allen.baum@...> wrote:

 

I'll stick my neck out again, and see if I  get corrected again. This is the most difficult part of the spec for me to interpret.

Priv spec sec 3.1.9 says

An interrupt i will trap to M-mode (causing the privilege mode to change to M-mode) if all of the following are true: 

(a) either the current privilege mode is M and the MIE bit in the mstatus register is set, or the current privilege mode has less privilege than M-mode; 
       which is equivalent to       (Privmode!=M | Privmode==M && mstatus.MIE==1)   (because less privilege than M is simply !=M)
(b) bit i is set in both mip and mie;
       which is equivalent to       & (mip[i]==1 & mie[i]==1)
(c) if register mideleg exists, bit i is not set in mideleg. 
       which is equivalent to       & mideleg[i]==0) (assuming Smode is implemented)

Trapping to Smode is similar in sec 4.1.3:

(a) either the current privilege mode is S and the SIE bit in the mstatus register is set, or the current privilege mode has less privilege than S-mode; 
       which is equivalent to       (Privmode<S | Privmode==S &  mstatus.SIE==1)  <-- this could be true if privmode=M also, 

 

How could that be true if privmode=M? You should never be able to trap to S-mode when executing in M-mode.

 



(b) bit i is set in both sip and sie;
       which is equivalent to       & (mip[i]==1 & mie[i]==1)

 

Not equivalent, since sip and sie are both masked by mideleg. That’s why the spec doesn’t need to explicitly mention mideleg here.

 

 



Since there is no sdeleg CSR, that term isn't used,
What it doesn't explicitly say is that mideleg[i] must be 1 else if won't get delegated to S - at least, not in this section
Instead, at the very very end of 3.1.9 it says

If an interrupt is delegated to S-mode by setting a bit in the mideleg register, it becomes visible in the sip register and is maskable using the sie register.:? 

So sip[i] can't be set unless mideleg is set - there is a hidden term there - but I'll make it explicit here:

so: (Privmode!=M | Privmode==M & mstatus.MIE==1) & (mip[i]==1 & mie[i]==1)  & mideleg[i]==0 --> trap to Mmode
      (Privmode < S | Privmode==S   &  sstatus. SIE==1) & (  sip[i]==1 &   sie[i]==1)  & mideleg[i]==1  --> trap to Smode

 

 

This is correct but that last term is unnecessary because of the masking of sip/sie.

 





Hypervisor complicates this a bit.

 

That’s putting it mildly!

 
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.