Supervisor Timer Interrupt and Delegation

[Vincent Siles]

Hi !

I'm trying to understand how to delegate the timer interrupt management to the supervisor mode.

My understanding is that I would set bit 5 in the mideleg register and then the timer interrupt will be notified to the supervisor mode instead of the machine mode.

What I would expect then is that a pending interrupt will be notified on bit 5 of the sip register. However, using riscv-qemu, I still get the interrupt notified on bit 7 (which should be WIRI) of the sip register.

Did I understood this mechanism correctly or am I doing something off ?

V.

[Andrew Waterman]

Setting bit X in mideleg only delegates interrupt X. Interrupts 7 and 5 are not related to each other in the hardware.

In the normal use case, you’d delegate STIs, but MTIs still go to M-mode. The M-mode MTI handler would use a CSRRSI instruction to set mip.STIP, so after MRET, the supervisor will take the STI.

On Fri, May 4, 2018 at 11:43 PM Vincent Siles <vincen...@ens-lyon.org> wrote:

Hi

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CADNVbF_Etufw3-YvhDX9BsriGna%3DENh6%2BRuEDGjwn08PCDo7uA%40mail.gmail.com.

[Vincent Siles]

So the only way to trigger the timer interrupt in supervisor mode is to write the bit from machine mode software ?

2018-05-05 8:58 GMT+02:00 Andrew Waterman <wate...@eecs.berkeley.edu>:

Setting bit X in mideleg only delegates interrupt X. Interrupts 7 and 5 are not related to each other in the hardware.

In the normal use case, you’d delegate STIs, but MTIs still go to M-mode. The M-mode MTI handler would use a CSRRSI instruction to set mip.STIP, so after MRET, the supervisor will take the STI.

On Fri, May 4, 2018 at 11:43 PM Vincent Siles <vincen...@ens-lyon.org> wrote:

Hi

I'm trying to understand how to delegate the timer interrupt management to the supervisor mode.

My understanding is that I would set bit 5 in the mideleg register and then the timer interrupt will be notified to the supervisor mode instead of the machine mode.

What I would expect then is that a pending interrupt will be notified on bit 5 of the sip register. However, using riscv-qemu, I still get the interrupt notified on bit 7 (which should be WIRI) of the sip register.

Did I understood this mechanism correctly or am I doing something off ?

V.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

[Michael Clark]

On 5/05/2018, at 7:04 PM, Vincent Siles <vincen...@ens-lyon.org> wrote:

So the only way to trigger the timer interrupt in supervisor mode is to write the bit from machine mode software ?

Yes that is correct, ... presently, however a model with 2 timer comparators, one for M mode and one for S mode would be possible, in much the same manner that the PLIC can deliver interrupts directly to S mode without monitor intervention. i.e. the model could be extended to timers and software interrupts.

There needs to be some evolution in the specification with respect to interrupts to support both software delegation as well as direct delivery of interrupts to S mode. Simple models will only require M mode interrupts, but more sophisticated models may have hardware controlled S mode interrupts.

1) M mode only, hardware controlled MEIP/MTIP/MSIP

2) M mode plus S mode, hardware controlled MEIP/MTIP/MSIP, software delegated SEIP/STIP/SSIP

3) M mode plus S mode, hardware controlled MEIP/MTIP/MSIP, hardware controlled SEIP, software delegated STIP/SSIP

4) M mode plus S mode, hardware controlled MEIP/MTIP/MSIP, hardware controlled SEIP/STIP/SSI

Currently QEMU models 1 and 3.

For example the mip.SEIP bit in the current specification can be either software delegated or hardware controlled. This actually presents unique problems. In QEMU we don’t allow software control of SEIP as a PLIC is usually attached and software control of this bit would interfere with hardware interrupt delivery. We intend to evolve the model in QEMU so that when the PLIC is attached, it claims control of SEIP, so that it can no longer be set by software. If a PLIC is not attached, Supervisor external interrupts could be software delegated like STIP/SSIP and the SEIP bit would be writable. It can’t be both user writable and controlled by hardware. Currently we have disallowed software writes to SEIP until we have better interrupt routing infrastructure i.e. interface that allows claims for these bits if hardware is attached to them.

Future interrupt controller models may allow direct delivery S mode software and timer interrupts without monitor intervention.

The PLIC is the starting point for interrupt controller models that have hardware delivered Supervisor interrupts with SEIP being hardware controlled.

I could speculate that there may even be PLIC variants that have separate M mode and an S mode MMIO control apertures by modifying the stride from { hart, mode } to { mode, hart }. I’m oversimplifying this for the sake of brevity, but currently S mode software has control of M mode interrupt routing, with the current models.

An alternative design would be to move the interrupt routing table base address and table updates to an SBI interface so we expose a virtualised interrupt routing interface to the Supervisor with an abstraction layer that can populate model specific interrupt routing tables.

This is an area that needs some evolution... we could create various flexible interrupt routing models in software (i.e. QEMU) but ultimately there needs to be hardware/RTL. The present focus has been on modelling the current specification and existing hardware...

[Vincent Siles]

I see. Thank you for this very detailed description !

V.

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/3CB182C8-A1C6-4164-9747-98DEA64B430C%40mac.com.