Date   

Re: Question about supervisor interrupt in M mode

Oscar Jupp
 

Dear Scott,
Thank you very much!

Regards,
Oscar Jupp

---- Replied Message ----
From Scott Johnson<scott.johnson@...>
Date 12/1/2022 02:29
To jupposcar@...<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode
From the privilege spec: "When a trap occurs in HS-mode or U-mode, it goes to M-mode, unless delegated by medeleg or mideleg, in which case it goes to HS-mode. When a trap occurs in VS-mode or VU-mode, it goes to M-mode, unless delegated by medeleg or mideleg, in which case it goes to HS-mode, unless further delegated by hedeleg or hideleg, in which case it goes to VS-mode.”


So no interrupts will ever go to VS-mode when in U-mode. They will go to either M-mode or HS-mode, regardless of hideleg.




On Nov 30, 2022, at 10:44 AM, jupposcar@... wrote:

Dear Scott,
Thank you. I want to ask another question.

When a hart is executing in U mode,doe the interrupt which trap to VS mode can be taken ?

---Original---
From: "Scott Johnson"<scott.johnson@...>
Date: Wed, Nov 30, 2022 23:47 PM
To: "jupposcar"<jupposcar@...>;
Cc: "tech-privileged@..."<tech-privileged@...>;
Subject: Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode

I think you’ve figured it out, but I’ve replied inline below anyway.


On Nov 30, 2022, at 1:24 AM, jupposcar <jupposcar@...> wrote:
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.”?


Yes, exactly.



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.

Yes, that’s correct.



But it's weird, sip.STIP is read-only zero when the mideleg[5]==0. It is enabled for what?


It will show up in mip.STIP which is where M-mode interrupts are seen.




Re: Question about supervisor interrupt in M mode

Allen Baum
 

Scott pointed out some issues about the way I framed the equations. I tried to make them symmetrical, to be more understandable, but Scott correctly points out there is some redundancy which is undescirbed.
Specifically:sip and sie are already ANDed with mideleg - which is described somewhere else, and makes it much harder to understand why this works.
I made that an explicit term, but did not change the equation from sie/sip to mip/mie to make it match the wording in the spec. 
Another way to do that is to separately describe how sie and sip are derived, and using them without the delegation term.

I haven't dug down into the hypervisor spec to see how these equations are affected by that, but I wish someone would.

On Wed, Nov 30, 2022 at 8:43 AM Jeff Scott <jeff.scott@...> wrote:

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 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!

 


Re: Question about supervisor interrupt in M mode

Scott Johnson
 

From the privilege spec: "When a trap occurs in HS-mode or U-mode, it goes to M-mode, unless delegated by medeleg or mideleg, in which case it goes to HS-mode. When a trap occurs in VS-mode or VU-mode, it goes to M-mode, unless delegated by medeleg or mideleg, in which case it goes to HS-mode, unless further delegated by hedeleg or hideleg, in which case it goes to VS-mode.”


So no interrupts will ever go to VS-mode when in U-mode. They will go to either M-mode or HS-mode, regardless of hideleg.




On Nov 30, 2022, at 10:44 AM, jupposcar@... wrote:

Dear Scott,
Thank you. I want to ask another question.

When a hart is executing in U mode,doe the interrupt which trap to VS mode can be taken ?

---Original---
From: "Scott Johnson"<scott.johnson@...>
Date: Wed, Nov 30, 2022 23:47 PM
To: "jupposcar"<jupposcar@...>;
Cc: "tech-privileged@..."<tech-privileged@...>;
Subject: Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode

I think you’ve figured it out, but I’ve replied inline below anyway.


On Nov 30, 2022, at 1:24 AM, jupposcar <jupposcar@...> wrote:
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.”?


Yes, exactly.



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.

Yes, that’s correct.



But it's weird, sip.STIP is read-only zero when the mideleg[5]==0. It is enabled for what?


It will show up in mip.STIP which is where M-mode interrupts are seen.




Re: Question about supervisor interrupt in M mode

Jeff Scott
 

Hi Scott,

 

The spec does say this:

 

 

Jeff

 

From: Scott Johnson <scott.johnson@...>
Sent: Wednesday, November 30, 2022 10:50 AM
To: Jeff Scott <jeff.scott@...>
Cc: Allen Baum <allen.baum@...>; Oscar Jupp <jupposcar@...>; tech-privileged@...
Subject: Re: [EXT] [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode

 

Caution: EXT Email

For me, the most important non-obvious thing was realizing that mip+mie are the only two interrupt pending/enable registers. All the other *ip/*ie are [masked and/or shifted] views into mip/mie, including: sip, hip, hvip, vsip, sie, hie, vsie.

 

Maybe this is considered an implementation detail and that’s why the spec doesn’t say it explicitly, but it was a big “Aha!” moment when I finally convinced myself this was true.

 



On Nov 30, 2022, at 10:43 AM, Jeff Scott <jeff.scott@...> wrote:

 

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 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!

 

 


Re: Question about supervisor interrupt in M mode

Scott Johnson
 

For me, the most important non-obvious thing was realizing that mip+mie are the only two interrupt pending/enable registers. All the other *ip/*ie are [masked and/or shifted] views into mip/mie, including: sip, hip, hvip, vsip, sie, hie, vsie.

Maybe this is considered an implementation detail and that’s why the spec doesn’t say it explicitly, but it was a big “Aha!” moment when I finally convinced myself this was true.


On Nov 30, 2022, at 10:43 AM, Jeff Scott <jeff.scott@...> wrote:

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 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!
 


Re: Question about supervisor interrupt in M mode

Oscar Jupp
 

Dear Scott,
Thank you. I want to ask another question.

When a hart is executing in U mode,doe the interrupt which trap to VS mode can be taken ?

---Original---
From: "Scott Johnson"<scott.johnson@...>
Date: Wed, Nov 30, 2022 23:47 PM
To: "jupposcar"<jupposcar@...>;
Cc: "tech-privileged@..."<tech-privileged@...>;
Subject: Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode

I think you’ve figured it out, but I’ve replied inline below anyway.


On Nov 30, 2022, at 1:24 AM, jupposcar <jupposcar@...> wrote:
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.”?


Yes, exactly.



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.

Yes, that’s correct.



But it's weird, sip.STIP is read-only zero when the mideleg[5]==0. It is enabled for what?


It will show up in mip.STIP which is where M-mode interrupts are seen.



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 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!

 


Re: Question about supervisor interrupt in M mode

Scott Johnson
 

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 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!


Re: Question about supervisor interrupt in M mode

Scott Johnson
 

I think you’ve figured it out, but I’ve replied inline below anyway.


On Nov 30, 2022, at 1:24 AM, jupposcar <jupposcar@...> wrote:
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.”?


Yes, exactly.



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.

Yes, that’s correct.



But it's weird, sip.STIP is read-only zero when the mideleg[5]==0. It is enabled for what?


It will show up in mip.STIP which is where M-mode interrupts are seen.



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 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.


Re: Question about supervisor interrupt in M mode

Allen Baum
 

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 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.


Re: Question about supervisor interrupt in M mode

Oscar Jupp
 

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.


Re: Question about supervisor interrupt in M mode

Oscar Jupp
 

Dear Jeff,

How can I search on previous Summit proceedings for this pseudocode equation for “enabled”?

Regards,
Oscar Jupp


---- Replied Message ----
From Jeff Scott<jeff.scott@...>
Date 11/30/2022 00:09
To scott.johnson@...<scott.johnson@...> ,
tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode

Yep, think of mti as first timer interrupt and sti as second timer interrupt.

 

A pseudocode equation for “enabled” in the spec would make this easier.  I think if you search on previous Summit proceedings, there was a presentation a long time ago that showed the equations.

 

Jeff

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Scott Johnson via lists.riscv.org
Sent: Tuesday, November 29, 2022 10:05 AM
To: tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode

 

Caution: EXT Email

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.


Re: Question about supervisor interrupt in M mode

Jeff Scott
 

Yep, think of mti as first timer interrupt and sti as second timer interrupt.

 

A pseudocode equation for “enabled” in the spec would make this easier.  I think if you search on previous Summit proceedings, there was a presentation a long time ago that showed the equations.

 

Jeff

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Scott Johnson via lists.riscv.org
Sent: Tuesday, November 29, 2022 10:05 AM
To: tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode

 

Caution: EXT Email

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.


Re: Question about supervisor interrupt in M mode

Scott Johnson
 

I think (and will be corrected if wrong) that the sentence should be interpreted as
When xIE=0, Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."

No, that is not what it says or means. Interrupts for lower-privilege modes are always globally disabled regardless of xIE (i.e. the bit in mstatus for the current privilege mode e.g. mstatus.mie when in M-mode).


Re: Question about supervisor interrupt in M mode

Scott Johnson
 

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.


Re: Question about supervisor interrupt in M mode

Oscar Jupp
 

Dear Allen,
Thank you for your replay.
How to understand next sentence: 

"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.”

Is it should be interpreted as:
“When xIE = 1,  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.”?

Regards,
Oscar Jupp

---- Replied Message ----
From Allen Baum<allen.baum@...>
Date 11/29/2022 21:24
To Oscar Jupp<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode
I think (and will be corrected if wrong) that the sentence should be interpreted as
When xIE=0, Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."


On Tue, Nov 29, 2022 at 3:50 AM Oscar Jupp <jupposcar@...> wrote:
Dear architect, 
Priv spec section 3.1.6.1 write: 
When a hart is executing in privilege mode x, interrupts are globally enabled when xIE=1 and globally disabled when xIE=0. Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."

So I think when a hart is executing in M mode, supervisor timer interrupt is disabled.

However, Priv spec section 3.1.8 write: 
For example, 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. By contrast, if mideleg[5] is clear, STIs can be taken  in any mode and regardless of current mode will transfer control to M-mode.

Is it contradictory.

Regards,
Oscar Jupp



Re: Question about supervisor interrupt in M mode

Allen Baum
 

I think (and will be corrected if wrong) that the sentence should be interpreted as
When xIE=0, Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."


On Tue, Nov 29, 2022 at 3:50 AM Oscar Jupp <jupposcar@...> wrote:
Dear architect, 
Priv spec section 3.1.6.1 write: 
When a hart is executing in privilege mode x, interrupts are globally enabled when xIE=1 and globally disabled when xIE=0. Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."

So I think when a hart is executing in M mode, supervisor timer interrupt is disabled.

However, Priv spec section 3.1.8 write: 
For example, 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. By contrast, if mideleg[5] is clear, STIs can be taken  in any mode and regardless of current mode will transfer control to M-mode.

Is it contradictory.

Regards,
Oscar Jupp



Question about supervisor interrupt in M mode

Oscar Jupp
 

Dear architect, 
Priv spec section 3.1.6.1 write: 
When a hart is executing in privilege mode x, interrupts are globally enabled when xIE=1 and globally disabled when xIE=0. Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."

So I think when a hart is executing in M mode, supervisor timer interrupt is disabled.

However, Priv spec section 3.1.8 write: 
For example, 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. By contrast, if mideleg[5] is clear, STIs can be taken  in any mode and regardless of current mode will transfer control to M-mode.

Is it contradictory.

Regards,
Oscar Jupp



Re: Question about mip and vsip

John Hauser
 

Greg Favor wrote:
The vsip CSR - as with all vs* CSRs - is only accessible by HS-mode (and
M-mode). As the vsip definition says, "When V=1, vsip and vsie substitute
for the usual sip and sie, so instructions that normally read or modify
sip/sie actually access vsip/vsie instead."
To emphasize Greg's point, the next sentence says, "When V=1, an
attempt to read or write a VS CSR directly by its own separate CSR
address causes a virtual instruction exception."

Oscar Jupp asked:
2.  Are the fields SEIP,SSIP,STIP in vsip real-only ? Can VS-mode
software modify these bit fields?
By the text quoted above, attempting to access vsip directly from VS
mode raises a virtual instruction exception. (V = 1 in VS mode.)

What about accessing sip from VS mode, which is really vsip? Because
the whole purpose of VS mode is to be a virtual S mode, the general
default assumption should be that VS mode provides an equivalent
execution environment as S mode. Therefore, what VS mode sees of
sip is what the Privileged Architecture says is true of sip in the
Supervisor-Level chapter (Section 4.1.3, "Supervisor Interrupt
Registers (sip and sie)"): "If implemented, SEIP is read-only
in sip...." "If implemented, STIP is read-only in sip...." "If
implemented, SSIP is writable in sip...."

- John Hauser

1 - 20 of 1205