I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode. That's why the interrupt pending bit shows up in bit 5 if delegated,

Comments embedded: I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1] How so? I would expect it to show up in

As far as I can tell, an implementation may, but is not required to, disallow it. If it is delegated, it shows up in the SIP. STIP bit But, if it is delegated, then it can only be cleared by an

Priv section 3.1.8 allows for but does not require that MTI be delegatable. So in that sense the answer is yes. But delegating MTI should generally be an unusual thing and some or many

Dear architect， Can the M interrupt such as MTI be delegated to S mode ? Regards, Oscar Jupp

Upon re-reading the relevant section in the hypervisor spec, I believe it is already specified that these should raise virtual-instruction exceptions when executed in VU-mode, hinging on the notion

What should the behavior of the SFENCE.W.INVAL and SFENCE.INVAL.IR instructions be when executed in VU mode? The spec clearly spells out the behavior of the other S/H Fence/Inval instructions in VU

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

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

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

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

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

Dear Scott, Thank you very much! Regards, Oscar Jupp

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

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

Hi Scott, The spec does say this: Jeff

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,

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

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

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