You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As shown in this figure, when the condition: if (mstatus.mpie == 1) is met in the above pseudo-code, the interrupt service program will be entered, but there is such a scenario:
a.set mie.mtie = 1 in M mode,
b.set mtimecmp = 0 ,which making mip.stip = 1 in M mode
c.Execute mret to change the privilege mode from M mode to S mode
At this point, an interrupt will cause a trap, but since mstatus.mie = 0, after the trap occurs, mstatus.mpie will also be equal to 0. This means that the condition mpie == 1 will never be met, thus rendering the interrupt unhandled. This scenario puzzles me greatly.
The text was updated successfully, but these errors were encountered:
@ZeyueShen, your question makes me realize that the AIA document should mention that software must be sure that mstatus.MPIE = 1 before executing an MRET to change to another privilege mode.
If we assume mstatus.MPIE = 1 before your step c, there is no problem. The MRET copies MPIE to MIE, and sets MPIE = 1. When the interrupt trap occurs, it then copies MIE to MPIE, and sets MIE = 0. Thus, MPIE is restored to 1 at the start of the trap handler.
As shown in this figure, when the condition: if (mstatus.mpie == 1) is met in the above pseudo-code, the interrupt service program will be entered, but there is such a scenario:
a.set mie.mtie = 1 in M mode,
b.set mtimecmp = 0 ,which making mip.stip = 1 in M mode
c.Execute mret to change the privilege mode from M mode to S mode
At this point, an interrupt will cause a trap, but since mstatus.mie = 0, after the trap occurs, mstatus.mpie will also be equal to 0. This means that the condition mpie == 1 will never be met, thus rendering the interrupt unhandled. This scenario puzzles me greatly.
The text was updated successfully, but these errors were encountered: