Date   

AR (Architecture Review) Committee minutes for 11/29/22

Greg Favor
 

We (the AR Committee) will be posting minutes of our (roughly) weekly meetings to discuss ISA issues that have been raised recently to the committee's attention, and to review RISC-V arch extensions that have been submitted for official AR (or for prelim review).

Here are this week's minutes.   (Note: As the RISC-V Summit and the holidays approach, this becomes a slower period for new AR requests and submissions, and hence general activity.)

Minutes from AR Committee meeting on 11/22/22
  • IOMMU detailed architecture review.
    • Some discussion about the IOMMU explicitly mandating (what is currently rather implicit) that requests by the IOMMU itself are coherent and consistent within the system (i.e. wrt harts and hart software).
    • Conversely, expecting to support IOMMU operation within an incoherent system would raise questions as to whether the IOMMU might be missing desirable arch features to better support use in such systems (i.e. simply saying that software would use cache maintenance instructions when interacting with the IOMMU may gloss over less obvious rough edges or problematic issues that haven't been consciously surfaced and considered).
  • Zicond.
    • Updates to create a final post-AR spec are in process and should be completed soon.  The name is shortened since other instruction extensions don't have the generic 'ops' suffix.

  • Zjid (I/D Consistency)
    • Discussion about this long outstanding ISA extension in development for a couple of years and thoughts about how to help facilitate things after the new year.
    • While at the same time it appears very unlikely that the current proposed Zjid extension can happen in time to be included in RVA23 ISA profiles.
    • So discussion about possible creation of a "Ziic" (Instruction cache Coherence) extension name for use in RVA profiles.  Which, while Zijd gestates, could be used in conjunction with Zifencei to more officially provide support for self and cross modifying code scenarios in the RVA23 profiles.


Re: Quetion about xRET instruction

Oscar Jupp
 

Dear architect,
Thank you for your reply.
I wonder how to emulate the hypervisor extension with trapping SRET on implementations that do not provide it.

Regards,
Oscar Jupp


---- Replied Message ----
From Ved Shanbhogue<ved@...>
Date 12/2/2022 21:21
To Oscar Jupp<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Quetion about xRET instruction
The ability to execute SRET in M-mode provides M-mode the
facility to trap, using TSR control, a SRET invoked in S-mode,
and after handling the trap to redo the SRET. The SRET invoked
in M-mode is not affected by the TSR control.

regards
ved



On Fri, Dec 02, 2022 at 08:33:51PM +0800, Oscar Jupp wrote:
<html>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'>
</head>
<body>
<style>
font{
line-height: 1.6;
}
ul,ol{
padding-left: 20px;
list-style-position: inside;
}
</style>
<div style = 'font-family:Helvetica,Helvetica,微软雅黑, 宋体; line-height:1.6;'>
<div ></div><div>
<div>
<span>
<br>
</span>
</div>
<div>
<span style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">Dear&nbsp;architect,&nbsp;</span></div><div><font face="Helvetica, Helvetica, 微软雅黑, 宋体">The spec section&nbsp;</font>3.3.2&nbsp;<span style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">said:</span></div><div><span>“</span>An xRET instruction can be executed in privilege mode x or higher, where executing a lower-privilege xRET instruction will pop the relevant lower-privilege interrupt enable and privilege mode stack.”</div><div>It's not clear to me what is the application scenario for doing this?<br>Why execute a SRET instruction in M-mode?<span><br></span></div><div>Just change SIE, SPIE, SPP? Need to change privileged mode and other CSRs?<br></div><div><span><br></span></div><div><div style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">Regards,</div><div style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">Oscar Jupp</div></div>
<div id="ntes-pcmac-signature" style="font-family:'Helvetica','Microsoft Yahei', '微软雅黑'">

<div style="font-size:14px; padding: 0;  margin:0;line-height: 14px;">
<div style="padding-bottom:6px;margin-bottom:10px;display:inline-block;">
<a href="https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1&amp;name=jupposcar&amp;uid=jupposcar%40gmail.com&amp;iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&amp;items=%5B%22jupposcar%40gmail.com%22%5D" style="display:block;background:#fff; max-width: 400px; _width: 400px;padding:15px 0 10px 0;text-decoration: none; outline:none;-webkit-tap-highlight-color:transparent;-webkit-text-size-adjust:none !important;text-size-adjust:none !important;">
<table cellpadding="0" style="width: 100%; max-width: 100%; table-layout: fixed; border-collapse: collapse;color: #9b9ea1;font-size: 14px;line-height:1.3;-webkit-text-size-adjust:none !important;text-size-adjust:none !important;">
<tbody style="font-family: 'PingFang SC', 'Hiragino Sans GB','WenQuanYi Micro Hei', 'Microsoft Yahei', '微软雅黑', verdana !important; word-wrap:break-word; word-break:break-all;-webkit-text-size-adjust:none !important;text-size-adjust:none !important;">
<tr class="firstRow">
<td width="38" style="padding:0; box-sizing: border-box; width: 38px;">
<img width="38" height="38" style="vertical-align:middle; width: 38px; height: 38px; border-radius:50%;" src="https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png">
</td>
<td style="padding: 0 0 0 10px; color: #31353b;">
<div style="font-size: 16px;font-weight:bold; width:100%; white-space: nowrap; overflow:hidden;text-overflow: ellipsis;">jupposcar</div>
</td>
</tr>
<tr width="100%" style="font-size: 14px !important; width: 100%;">
<td colspan="2" style="padding:10px 0 0 0; font-size:14px !important; width: 100%;">
<div style="width: 100%;font-size: 14px !important;word-wrap:break-word;word-break:break-all;">jupposcar@...</div>
</td>
</tr>
</tbody>
</table>
</a>
</div>
</div>
</div>
<br>
</div><!--�-->
</div>
</body>
</html>


Re: Quetion about xRET instruction

Allen Baum
 

I first read this as TSR meaning "Trap Service Routine", 
but now I understand that it is the mstatus.TSR bit.


On Fri, Dec 2, 2022 at 5:21 AM Ved Shanbhogue <ved@...> wrote:
The ability to execute SRET in M-mode provides M-mode the
facility to trap, using TSR control, a SRET invoked in S-mode,
and after handling the trap to redo the SRET. The SRET invoked
in M-mode is not affected by the TSR control.

regards
ved



On Fri, Dec 02, 2022 at 08:33:51PM +0800, Oscar Jupp wrote:
><html>
><head>
>    <meta http-equiv='Content-Type' content='text/html; charset=UTF-8'>
></head>
><body>
><style>
>    font{
>        line-height: 1.6;
>    }
>    ul,ol{
>        padding-left: 20px;
>        list-style-position: inside;
>    }
></style>
><div style = 'font-family:Helvetica,Helvetica,微软雅黑, 宋体; line-height:1.6;'>
>    <div ></div><div>
>    <div>
>        <span>
>            <br>
>        </span>
>    </div>
>    <div>
>        <span style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">Dear&nbsp;architect,&nbsp;</span></div><div><font face="Helvetica, Helvetica, 微软雅黑, 宋体">The spec section&nbsp;</font>3.3.2&nbsp;<span style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">said:</span></div><div><span>“</span>An xRET instruction can be executed in privilege mode x or higher, where executing a lower-privilege xRET instruction will pop the relevant lower-privilege interrupt enable and privilege mode stack.”</div><div>It's not clear to me what is the application scenario for doing this?<br>Why execute a SRET instruction in M-mode?<span><br></span></div><div>Just change SIE, SPIE, SPP? Need to change privileged mode and other CSRs?<br></div><div><span><br></span></div><div><div style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">Regards,</div><div style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">Oscar Jupp</div></div>
>    <div id="ntes-pcmac-signature" style="font-family:'Helvetica','Microsoft Yahei', '微软雅黑'">
>     
>    <div style="font-size:14px; padding: 0;  margin:0;line-height: 14px;">
>        <div style="padding-bottom:6px;margin-bottom:10px;display:inline-block;">
>                    <a href="https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1&amp;name=jupposcar&amp;uid=jupposcar%40gmail.com&amp;iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&amp;items=%5B%22jupposcar%40gmail.com%22%5D" style="display:block;background:#fff; max-width: 400px; _width: 400px;padding:15px 0 10px 0;text-decoration: none; outline:none;-webkit-tap-highlight-color:transparent;-webkit-text-size-adjust:none !important;text-size-adjust:none !important;">
>            <table cellpadding="0" style="width: 100%; max-width: 100%; table-layout: fixed; border-collapse: collapse;color: #9b9ea1;font-size: 14px;line-height:1.3;-webkit-text-size-adjust:none !important;text-size-adjust:none !important;">
>                <tbody style="font-family: 'PingFang SC', 'Hiragino Sans GB','WenQuanYi Micro Hei', 'Microsoft Yahei', '微软雅黑', verdana !important; word-wrap:break-word; word-break:break-all;-webkit-text-size-adjust:none !important;text-size-adjust:none !important;">
>                    <tr class="firstRow">
>                            <td width="38" style="padding:0; box-sizing: border-box; width: 38px;">
>                                <img width="38" height="38" style="vertical-align:middle; width: 38px; height: 38px; border-radius:50%;" src="https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png">
>                            </td>
>                            <td style="padding: 0 0 0 10px; color: #31353b;">
>                                <div style="font-size: 16px;font-weight:bold; width:100%; white-space: nowrap; overflow:hidden;text-overflow: ellipsis;">jupposcar</div>
>                            </td>
>                    </tr>
>                        <tr width="100%" style="font-size: 14px !important; width: 100%;">
>                            <td colspan="2" style="padding:10px 0 0 0; font-size:14px !important; width: 100%;">
>                                    <div style="width: 100%;font-size: 14px !important;word-wrap:break-word;word-break:break-all;">jupposcar@...</div>
>                            </td>
>                        </tr>
>                </tbody>
>            </table>
>        </a>
>        </div>
>    </div>
> </div>
>    <br>
></div><!--�-->
></div>
></body>
></html>
>
> <div width="1" style="color:white;clear:both"></div>
>






Re: Quetion about xRET instruction

Ved Shanbhogue
 

The ability to execute SRET in M-mode provides M-mode the
facility to trap, using TSR control, a SRET invoked in S-mode,
and after handling the trap to redo the SRET. The SRET invoked
in M-mode is not affected by the TSR control.

regards
ved

On Fri, Dec 02, 2022 at 08:33:51PM +0800, Oscar Jupp wrote:
<html>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'>
</head>
<body>
<style>
font{
line-height: 1.6;
}
ul,ol{
padding-left: 20px;
list-style-position: inside;
}
</style>
<div style = 'font-family:Helvetica,Helvetica,微软雅黑, 宋体; line-height:1.6;'>
<div ></div><div>
<div>
<span>
<br>
</span>
</div>
<div>
<span style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">Dear&nbsp;architect,&nbsp;</span></div><div><font face="Helvetica, Helvetica, 微软雅黑, 宋体">The spec section&nbsp;</font>3.3.2&nbsp;<span style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">said:</span></div><div><span>“</span>An xRET instruction can be executed in privilege mode x or higher, where executing a lower-privilege xRET instruction will pop the relevant lower-privilege interrupt enable and privilege mode stack.”</div><div>It's not clear to me what is the application scenario for doing this?<br>Why execute a SRET instruction in M-mode?<span><br></span></div><div>Just change SIE, SPIE, SPP? Need to change privileged mode and other CSRs?<br></div><div><span><br></span></div><div><div style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">Regards,</div><div style="font-family: Helvetica, Helvetica, 微软雅黑, 宋体;">Oscar Jupp</div></div>
<div id="ntes-pcmac-signature" style="font-family:'Helvetica','Microsoft Yahei', '微软雅黑'">
<div style="font-size:14px; padding: 0; margin:0;line-height: 14px;">
<div style="padding-bottom:6px;margin-bottom:10px;display:inline-block;">
<a href="https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1&;name=jupposcar&amp;uid=jupposcar%40gmail.com&amp;iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&amp;items=%5B%22jupposcar%40gmail.com%22%5D" style="display:block;background:#fff; max-width: 400px; _width: 400px;padding:15px 0 10px 0;text-decoration: none; outline:none;-webkit-tap-highlight-color:transparent;-webkit-text-size-adjust:none !important;text-size-adjust:none !important;">
<table cellpadding="0" style="width: 100%; max-width: 100%; table-layout: fixed; border-collapse: collapse;color: #9b9ea1;font-size: 14px;line-height:1.3;-webkit-text-size-adjust:none !important;text-size-adjust:none !important;">
<tbody style="font-family: 'PingFang SC', 'Hiragino Sans GB','WenQuanYi Micro Hei', 'Microsoft Yahei', '微软雅黑', verdana !important; word-wrap:break-word; word-break:break-all;-webkit-text-size-adjust:none !important;text-size-adjust:none !important;">
<tr class="firstRow">
<td width="38" style="padding:0; box-sizing: border-box; width: 38px;">
<img width="38" height="38" style="vertical-align:middle; width: 38px; height: 38px; border-radius:50%;" src="https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png">
</td>
<td style="padding: 0 0 0 10px; color: #31353b;">
<div style="font-size: 16px;font-weight:bold; width:100%; white-space: nowrap; overflow:hidden;text-overflow: ellipsis;">jupposcar</div>
</td>
</tr>
<tr width="100%" style="font-size: 14px !important; width: 100%;">
<td colspan="2" style="padding:10px 0 0 0; font-size:14px !important; width: 100%;">
<div style="width: 100%;font-size: 14px !important;word-wrap:break-word;word-break:break-all;">jupposcar@...</div>
</td>
</tr>
</tbody>
</table>
</a>
</div>
</div>
</div>
<br>
</div><!--�-->
</div>
</body>
</html>

<div width="1" style="color:white;clear:both"></div>


Quetion about xRET instruction

Oscar Jupp
 


Dear architect, 
The spec section 3.3.2 said:
An xRET instruction can be executed in privilege mode x or higher, where executing a lower-privilege xRET instruction will pop the relevant lower-privilege interrupt enable and privilege mode stack.”
It's not clear to me what is the application scenario for doing this?
Why execute a SRET instruction in M-mode?
Just change SIE, SPIE, SPP? Need to change privileged mode and other CSRs?

Regards,
Oscar Jupp


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

1 - 20 of 1210