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

Re: Question about supervisor interrupt in M mode

Oscar Jupp
 

Dear architect，
I thought about it for a long time and finally figured it out.
It's not weird, sip.STIP is read-only zero when the mideleg[5]==0. But hart is in S mode，but it have to take STI and trap to M mode.So it is enabled.

Regards,
Oscar Jupp

---- Replied Message ----
From Allen Baum<allen.baum@...>
Date 11/30/2022 16:34
To Oscar Jupp<jupposcar@...>
Cc Scott Johnson<scott.johnson@...> ,
 tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode
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, 
(b) bit i is set in both sip and sie;
       which is equivalent to       & (mip[i]==1 & mie[i]==1)

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


Hypervisor complicates this a bit.

Now that I've probablyh misled you, let the corrections begin...

On Tue, Nov 29, 2022 at 11:24 PM Oscar Jupp <jupposcar@...> wrote:
Dear Scott，
Thank you for your reply.

Do you mean that :
“Supervisor timer interrupt if mideleg[5]==0 is a interrupt for M mode.
 Supervisor timer interrupt if mideleg[5]==1 is a interrupt for S mode.”?

If yes, how to understand the next sentences:
"Interrupts for higher-privilege modes, y>x, are always globally enabled regardless of the setting of the global yIE
bit for the higher-privilege mode.”

My understanding is as follows：
suppose x = S mode,  y = M mode.
When a hart is executing in S mode, supervisor timer interrupt is always enabled if mideleg[5]==0 regardless of the setting of the global mIE bit.
But it's weird, sip.STIP is read-only zero when the mideleg[5]==0. It is enabled for what?

Regards,
Oscar Jupp

---- Replied Message ----
From Scott Johnson<scott.johnson@...>
Date 11/30/2022 00:04
To <tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode
Oscar, what you are missing is that STI, despite its name, is not for a lower-privilege mode when mideleg[5]==0. In that case the STI is destined for M-mode and therefore can be taken in any privilege mode.

To correct your statement: When a hart is executing in M mode, supervisor timer interrupt is disabled if mideleg[5]==1.

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