|
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.
|
jupposcar
|
|
jupposcar@...
|
|
|
|
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.
|
|
jupposcar
|
|
jupposcar@...
|
|
|
|
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.”?
|
|
jupposcar
|
|
jupposcar@...
|
---- Replied Message ----
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."
toggle quoted message
Show quoted text
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.
|
|
jupposcar
|
|
jupposcar@...
|
|
|
|
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.
|
|
|
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).
|
|
|
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
toggle quoted message
Show quoted text
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.
|
|
|
Dear Jeff,
How can I search on previous Summit proceedings for this pseudocode equation for “enabled”?
|
|
jupposcar
|
|
jupposcar@...
|
---- Replied Message ----
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
toggle quoted message
Show quoted text
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.
|
|
|
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?
|
|
jupposcar
|
|
jupposcar@...
|
---- Replied Message ----
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.
|
|
|
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 i is set in both sip and sie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
Since there is no sdeleg CSR, that term isn't used,
What it doesn't explicitly say is that mideleg[i] must be 1 else if won't get delegated to S - at least, not in this section
Instead, at the very very end of 3.1.9 it says
If an interrupt is delegated to S-mode by setting a bit in the mideleg register, it becomes
visible in the sip register and is maskable using the sie register.:?
So sip[i] can't be set unless mideleg is set - there is a hidden term there - but I'll make it explicit here: so: (Privmode!=M | Privmode==M & mstatus.MIE==1) & (mip[i]==1 & mie[i]==1) & mideleg[i]==0 --> trap to Mmode (Privmode < S | Privmode==S & sstatus. SIE==1) & ( sip[i]==1 & sie[i]==1) & mideleg[i]==1 --> trap to Smode Hypervisor complicates this a bit. Now that I've probablyh misled you, let the corrections begin... On Tue, Nov 29, 2022 at 11:24 PM Oscar Jupp < jupposcar@...> wrote:
Dear Scott， Thank you for your reply.
Do you mean that : “Supervisor timer interrupt if mideleg[5]==0 is a interrupt for M mode. Supervisor timer interrupt if mideleg[5]==1 is a interrupt for S mode.”?
If yes, how to understand the next sentences: "Interrupts for
higher-privilege modes, y>x, are always globally enabled regardless of the setting of the global yIE
bit for the higher-privilege mode.”
My understanding is as follows： suppose x = S mode, y = M mode. When a hart is executing in S mode, supervisor timer interrupt is always enabled if mideleg[5]==0 regardless of the setting of the global mIE bit. But it's weird, sip.STIP is read-only zero when the mideleg[5]==0. It is enabled for what?
|
|
jupposcar
|
|
jupposcar@...
|
---- Replied Message ----
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.
|
|
|
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.
|
|
jupposcar
|
|
jupposcar@...
|
---- Replied Message ----
I'll stick my neck out again, and see if I get corrected again. This is the most difficult part of the spec for me to interpret. Priv spec sec 3.1.9 says An interrupt i will trap to M-mode (causing the privilege mode to change to M-mode) if all of
the following are true:
(a) either the current privilege mode is M and the MIE bit in the mstatus
register is set, or the current privilege mode has less privilege than M-mode;
which is equivalent to (Privmode!=M | Privmode==M && mstatus.MIE==1) (because less privilege than M is simply !=M)
(b) bit i is set in both
mip and mie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
(c) if register mideleg exists, bit i is not set in mideleg.
which is equivalent to & mideleg[i]==0) (assuming Smode is implemented) Trapping to Smode is similar in sec 4.1.3: (a) either the current privilege mode is S and the SIE bit in the mstatus register is set, or the current privilege mode has less privilege than S-mode;
which is equivalent to (Privmode<S | Privmode==S & mstatus.SIE==1) <-- this could be true if privmode=M also,
(b) bit i is set in both sip and sie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
Since there is no sdeleg CSR, that term isn't used,
What it doesn't explicitly say is that mideleg[i] must be 1 else if won't get delegated to S - at least, not in this section
Instead, at the very very end of 3.1.9 it says
If an interrupt is delegated to S-mode by setting a bit in the mideleg register, it becomes
visible in the sip register and is maskable using the sie register.:?
So sip[i] can't be set unless mideleg is set - there is a hidden term there - but I'll make it explicit here: so: (Privmode!=M | Privmode==M & mstatus.MIE==1) & (mip[i]==1 & mie[i]==1) & mideleg[i]==0 --> trap to Mmode (Privmode < S | Privmode==S & sstatus. SIE==1) & ( sip[i]==1 & sie[i]==1) & mideleg[i]==1 --> trap to Smode Hypervisor complicates this a bit. Now that I've probablyh misled you, let the corrections begin... On Tue, Nov 29, 2022 at 11:24 PM Oscar Jupp < jupposcar@...> wrote:
Dear Scott， Thank you for your reply.
Do you mean that : “Supervisor timer interrupt if mideleg[5]==0 is a interrupt for M mode. Supervisor timer interrupt if mideleg[5]==1 is a interrupt for S mode.”?
If yes, how to understand the next sentences: "Interrupts for
higher-privilege modes, y>x, are always globally enabled regardless of the setting of the global yIE
bit for the higher-privilege mode.”
My understanding is as follows： suppose x = S mode, y = M mode. When a hart is executing in S mode, supervisor timer interrupt is always enabled if mideleg[5]==0 regardless of the setting of the global mIE bit. But it's weird, sip.STIP is read-only zero when the mideleg[5]==0. It is enabled for what?
|
|
jupposcar
|
|
jupposcar@...
|
---- Replied Message ----
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.
|
|
|
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.
|
|
|
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 i is set in both sip and sie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
Not equivalent, since sip and sie are both masked by mideleg. That’s why the spec doesn’t need to explicitly mention mideleg here.
Since there is no sdeleg CSR, that term isn't used,
What it doesn't explicitly say is that mideleg[i] must be 1 else if won't get delegated to S - at least, not in this section
Instead, at the very very end of 3.1.9 it says
If an interrupt is delegated to S-mode by setting a bit in the mideleg register, it becomes
visible in the sip register and is maskable using the sie register.:?
So sip[i] can't be set unless mideleg is set - there is a hidden term there - but I'll make it explicit here: so: (Privmode!=M | Privmode==M & mstatus.MIE==1) & (mip[i]==1 & mie[i]==1) & mideleg[i]==0 --> trap to Mmode (Privmode < S | Privmode==S & sstatus. SIE==1) & ( sip[i]==1 & sie[i]==1) & mideleg[i]==1 --> trap to Smode
This is correct but that last term is unnecessary because of the masking of sip/sie.
Hypervisor complicates this a bit.
That’s putting it mildly!
|
|
|
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
toggle quoted message
Show quoted text
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:
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.
An interrupt i
will trap to M-mode (causing the privilege mode to change to M-mode) if all of the following are true:
(a) either the current privilege mode is M and the MIE bit in the
mstatus register is set, or the current privilege mode has less privilege than M-mode;
which is equivalent to (Privmode!=M | Privmode==M && mstatus.MIE==1) (because less privilege than M is simply !=M)
(b) bit i
is set in both mip
and mie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
(c) if register mideleg
exists, bit i
is not set in mideleg.
which is equivalent to & mideleg[i]==0) (assuming Smode is implemented)
Trapping to Smode is similar in sec 4.1.3:
(a) either the current privilege mode is S and the SIE bit in the mstatus register is set, or the current privilege mode
has less privilege than S-mode;
which is equivalent to (Privmode<S | Privmode==S & mstatus.SIE==1) <-- this could be true if privmode=M also,
How could that be true if privmode=M? You should never be able to trap to S-mode when executing in M-mode.
(b) bit i is set in both sip and sie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
Not equivalent, since sip and sie are both masked by mideleg. That’s why the spec doesn’t need to explicitly mention mideleg here.
Since there is no sdeleg CSR, that term isn't used,
What it doesn't explicitly say is that mideleg[i] must be 1 else if won't get delegated to S - at least, not in this section
Instead, at the very very end of 3.1.9 it says
If an interrupt is delegated to S-mode by setting a bit in the
mideleg register, it becomes visible in the
sip register and is maskable using the
sie register.:?
So sip[i] can't be set unless mideleg is set - there is a hidden term there - but I'll make it explicit here:
so: (Privmode!=M | Privmode==M & mstatus.MIE==1) & (mip[i]==1 & mie[i]==1) & mideleg[i]==0 --> trap to Mmode
(Privmode < S | Privmode==S & sstatus. SIE==1) & ( sip[i]==1 & sie[i]==1) & mideleg[i]==1 --> trap to Smode
This is correct but that last term is unnecessary because of the masking of sip/sie.
Hypervisor complicates this a bit.
That’s putting it mildly!
|
|
|
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.
|
|
|
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 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:
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. An interrupt i will trap to M-mode (causing the privilege mode to change to M-mode) if all of the following are true:
(a) either the current privilege mode is M and the MIE bit in the mstatus register is set, or the current privilege mode has less privilege than M-mode;
which is equivalent to (Privmode!=M | Privmode==M && mstatus.MIE==1) (because less privilege than M is simply !=M)
(b) bit i is set in both mip and mie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
(c) if register mideleg exists, bit i is not set in mideleg.
which is equivalent to & mideleg[i]==0) (assuming Smode is implemented) Trapping to Smode is similar in sec 4.1.3: (a) either the current privilege mode is S and the SIE bit in the mstatus register is set, or the current privilege mode has less privilege than S-mode;
which is equivalent to (Privmode<S | Privmode==S & mstatus.SIE==1) <-- this could be true if privmode=M also,
How could that be true if privmode=M? You should never be able to trap to S-mode when executing in M-mode.
(b) bit i is set in both sip and sie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
Not equivalent, since sip and sie are both masked by mideleg. That’s why the spec doesn’t need to explicitly mention mideleg here.
Since there is no sdeleg CSR, that term isn't used,
What it doesn't explicitly say is that mideleg[i] must be 1 else if won't get delegated to S - at least, not in this section
Instead, at the very very end of 3.1.9 it says If an interrupt is delegated to S-mode by setting a bit in the mideleg register, it becomes visible in the sip register and is maskable using the sie register.:?
So sip[i] can't be set unless mideleg is set - there is a hidden term there - but I'll make it explicit here:
so: (Privmode!=M | Privmode==M & mstatus.MIE==1) & (mip[i]==1 & mie[i]==1) & mideleg[i]==0 --> trap to Mmode
(Privmode < S | Privmode==S & sstatus. SIE==1) & ( sip[i]==1 & sie[i]==1) & mideleg[i]==1 --> trap to Smode
This is correct but that last term is unnecessary because of the masking of sip/sie.
Hypervisor complicates this a bit.
That’s putting it mildly!
|
|
|
Hi Scott,
The spec does say this:
Jeff
toggle quoted message
Show quoted text
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.
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.
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:
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.
An interrupt i will
trap to M-mode (causing the privilege mode to change to M-mode) if all of the following are true:
(a) either the current privilege mode is M and the MIE bit in the mstatus register
is set, or the current privilege mode has less privilege than M-mode;
which is equivalent to (Privmode!=M | Privmode==M && mstatus.MIE==1) (because less privilege than M is
simply !=M)
(b) bit i is
set in both mip and mie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
(c) if register mideleg exists,
bit i is not set in mideleg.
which is equivalent to & mideleg[i]==0) (assuming Smode is implemented)
Trapping to Smode is similar in sec 4.1.3:
(a) either the current privilege mode is S and the SIE bit in the mstatus register
is set, or the current privilege mode has less privilege than S-mode;
which is equivalent to (Privmode<S | Privmode==S & mstatus.SIE==1) <-- this could be true if privmode=M also,
How could that be true if privmode=M? You should never be able to trap to S-mode when executing in M-mode.
(b) bit i is set in both sip and sie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
Not equivalent, since sip and sie are both masked by mideleg. That’s why the spec doesn’t need to explicitly mention mideleg here.
Since there is no sdeleg CSR, that term isn't used,
What it doesn't explicitly say is that mideleg[i] must be 1 else if won't get delegated to S - at least, not in this section
Instead, at the very very end of 3.1.9 it says
If an interrupt is delegated to S-mode by setting a bit in the mideleg register,
it becomes visible in the sip register and
is maskable using the sie register.:?
So sip[i] can't be set unless mideleg is set - there is a hidden term there - but I'll make it explicit here:
so: (Privmode!=M | Privmode==M & mstatus.MIE==1) & (mip[i]==1 & mie[i]==1) & mideleg[i]==0 --> trap to Mmode
(Privmode < S | Privmode==S & sstatus. SIE==1) & ( sip[i]==1 & sie[i]==1) & mideleg[i]==1 --> trap to Smode
This is correct but that last term is unnecessary because of the masking of sip/sie.
Hypervisor complicates this a bit.
That’s putting it mildly!
|
|
|
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.
|
|
|
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.
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
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:
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.
An interrupt i
will trap to M-mode (causing the privilege mode to change to M-mode) if all of the following are true:
(a) either the current privilege mode is M and the MIE bit in the
mstatus register is set, or the current privilege mode has less privilege than M-mode;
which is equivalent to (Privmode!=M | Privmode==M && mstatus.MIE==1) (because less privilege than M is simply !=M)
(b) bit i
is set in both mip
and mie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
(c) if register mideleg
exists, bit i
is not set in mideleg.
which is equivalent to & mideleg[i]==0) (assuming Smode is implemented)
Trapping to Smode is similar in sec 4.1.3:
(a) either the current privilege mode is S and the SIE bit in the mstatus register is set, or the current privilege mode
has less privilege than S-mode;
which is equivalent to (Privmode<S | Privmode==S & mstatus.SIE==1) <-- this could be true if privmode=M also,
How could that be true if privmode=M? You should never be able to trap to S-mode when executing in M-mode.
(b) bit i is set in both sip and sie;
which is equivalent to & (mip[i]==1 & mie[i]==1)
Not equivalent, since sip and sie are both masked by mideleg. That’s why the spec doesn’t need to explicitly mention mideleg here.
Since there is no sdeleg CSR, that term isn't used,
What it doesn't explicitly say is that mideleg[i] must be 1 else if won't get delegated to S - at least, not in this section
Instead, at the very very end of 3.1.9 it says
If an interrupt is delegated to S-mode by setting a bit in the
mideleg register, it becomes visible in the
sip register and is maskable using the
sie register.:?
So sip[i] can't be set unless mideleg is set - there is a hidden term there - but I'll make it explicit here:
so: (Privmode!=M | Privmode==M & mstatus.MIE==1) & (mip[i]==1 & mie[i]==1) & mideleg[i]==0 --> trap to Mmode
(Privmode < S | Privmode==S & sstatus. SIE==1) & ( sip[i]==1 & sie[i]==1) & mideleg[i]==1 --> trap to Smode
This is correct but that last term is unnecessary because of the masking of sip/sie.
Hypervisor complicates this a bit.
That’s putting it mildly!
|
|
|
Dear Scott, Thank you very much!
|
|
jupposcar
|
|
jupposcar@...
|
---- Replied Message ----
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.
toggle quoted message
Show quoted text
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.
|
|
|
