The question was about delegating MTIP, not STIP. I don’t know why you’re talking about STIP at all; that’s a different interrupt entirely. MTIP vs STIP has nothing to do with what privilege mode will handle the interrupt. That is determined entirely by mideleg, not by the name of the interrupt.
MTIP is invisible to S-mode because mideleg[7] is 0. Just like STIP is invisible to S-mode if mideleg[5] is 0.
I don’t know what xstatus refers to — is that mstatus/sstatus? Bits 11:9 of those have nothing to do with interrupts?
My mistake about PLIC; I meant that MTIP is driven by CLINT. The MTIMECMP CSR is not accessed through CSRRW instructions. It is memory-mapped. An implementation could conceivably allow PMP and/or PMA settings that would allow S-mode access to this CSR. Like you say, not a good idea. Just like delegating MTIP to S-mode is probably not a good idea.
But all of this is academic and is just speculation about how it would work if mideleg[7] was writable, which I don’t think any reasonable implementation would support.
On Dec 7, 2022, at 3:52 PM, Allen Baum <allen.baum@...> wrote:
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, but bit 7 if not.
MTIP is NOT driven by the PLIC; the PLIC only sends external interrupts, not timer interrupts (which correspond to bits xstatus[11..9]
The timer interrupt can only be reset by writing the MTIMECMP CSR, which is M-only. An implementation could have a custom alias to that that would enable Smode to write it,
but that;s dangerous, as that means that Scode could prevent Mmode from getting timer interrupts by setting the CSR to a value in the far future.
Comments embedded:
As far as I can tell, an implementation may, but is not required to, disallow it.
I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1]
If it is delegated, it shows up in the SIP. STIP bit
How so? I would expect it to show up in SIP[7], which is defined as 0 in the privileged spec, but corresponds to the MTIP bit. There is no mechanism for an interrupt to show up in a different position in SIP vs MIP.
But, if it is delegated, then it can only be cleared by an ECALL to Mmode SW..
MTIP is controlled by a wire driven by a memory-mapped interrupt controller (e.g. PLIC). If an SBI decided to delegate MTI to S-mode then they might also allow S-mode software to access the interrupt controller too, removing any need for an ECALL.
