I think you’ve figured it out, but I’ve replied inline below anyway. Yes, exactly. Yes, that’s correct. It will show up in mip.STIP which is where M-mode interrupts are seen.

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

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(a) either the current privilege mode is M and

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

Dear Jeff, How can I search on previous Summit proceedings for this pseudocode equation for “enabled”? Regards, Oscar Jupp

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

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

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

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

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

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

Greg Favor wrote: 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

Thanks for Allen and Greg! I learn a lot from you.

I believe I would agree with what Allen said. Regarding shadows, note that Priv section 2.1 says: CSRsthat are read-only at some lower privilege level are shadowed into separate CSR addresses if

Without a deep understanding of these particular bits (and Greg will correct me if I'm wrong) there are some general rules that should apply (I am unaware of any exceptions to this off the top of my

Per Priv section 2.2, 0x344 is read/write. And hip is also read-write. So the mip aliases of these hip bits are also read/write in mip. First, I think you mean section 5.1.3 in the latest draft of

Dear Greg, Thanks for your reply. 1. You said : “Priv section 9.4.3 defines these bits as aliases (of bits in hip), so yes - M-mode software can modify these bits.” But I don’t know they are

Priv section 9.4.3 defines these bits as aliases (of bits in hip), so yes - M-mode software can modify these bits. The vsip CSR - as with all vs* CSRs - is only accessible by HS-mode (and M-mode). As

Dear architect, CSR mip and vsip are both WARL. But SPEC did not specify that : 1. Are the fields VSEIP，VSSIP，VSTIP in mip real-only ? Can M-mode software modify

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