Inter-processor interrupts in machine mode

Sebastian Huber

unread,

Jul 27, 2018, 7:17:35 AM7/27/18

to RISC-V SW Dev

Hello,

I port currently the real-time operating system RTEMS to RISC-V. I worked only with Qemu so far, so I don't know the real chips. The operating system runs together with the application in machine mode. I had to patch Qemu a bit to get it working. The patch review was very interesting for me.

https://github.com/riscv/riscv-qemu/pull/155

Inter-processor interrupts are triggered by a write to the CLINT msip register. I naively thought that I can clear the software interrupt by the target hart via a write to the mip register. This seems to be forbidden (mip is read-only). So the only way to set/clear software interrupts is via concurrent writes to the memory-mapped CLINT msip register?

Rishiyur Nikhil

unread,

Jul 27, 2018, 10:29:39 AM7/27/18

to Sebastian Huber, RISC-V SW Dev

Yes, the only way to clear MIP.MSIP is to write to the memory-mapped location that (eventually) will clear the bit.

Similarly, the only way to clear MIP.MTIP is to write to the memory-mapped MTIMECMP location that (eventually) will clear the bit.

The latency for these is unspecified (will vary across implementations, and may vary even within an implementation).

Nikhil

--
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/c46d9c3b-64b3-41bf-92ef-1762e5cddfd8%40groups.riscv.org.

Paul Miranda

unread,

Jul 27, 2018, 10:07:02 PM7/27/18

to RISC-V SW Dev, seb...@gmail.com

Is there a spec for the PLIC register set (or any memory mapped register)? Or are they all considered implementation-dependent?

On Friday, July 27, 2018 at 9:29:39 AM UTC-5, nikhil wrote:

Yes, the only way to clear MIP.MSIP is to write to the memory-mapped location that (eventually) will clear the bit.
Similarly, the only way to clear MIP.MTIP is to write to the memory-mapped MTIMECMP location that (eventually) will clear the bit.
The latency for these is unspecified (will vary across implementations, and may vary even within an implementation).

Nikhil

On Fri, Jul 27, 2018 at 7:17 AM, Sebastian Huber <seb...@gmail.com> wrote:

Hello,

I port currently the real-time operating system RTEMS to RISC-V. I worked only with Qemu so far, so I don't know the real chips. The operating system runs together with the application in machine mode. I had to patch Qemu a bit to get it working. The patch review was very interesting for me.

https://github.com/riscv/riscv-qemu/pull/155

Inter-processor interrupts are triggered by a write to the CLINT msip register. I naively thought that I can clear the software interrupt by the target hart via a write to the mip register. This seems to be forbidden (mip is read-only). So the only way to set/clear software interrupts is via concurrent writes to the memory-mapped CLINT msip register?

--
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.

Michael Clark

unread,

Jul 28, 2018, 9:51:35 AM7/28/18

to Sebastian Huber, RISC-V SW Dev

Hi Sebastian,

Apologies if I seemed somewhat curt in my reply to your PR however it’s for the best (although I don’t think I was exactly curt as I took the time to extract the relevant wording from the Privileged ISA spec).

We are trying to make QEMU match hardware as closely as possible and thus if your implementation works in QEMU then there is a very high likelihood that it will work with few or no modifications on real hardware. That IMHO is a good thing.

It is indeed a possible for a RISC-V hardware implementation of RDTIME and I was thinking twice before closing your PR. As I mentioned, if we were to add hardware RDTIME, we would then need to add a CPU feature flag to distinguish between processor models that implement RDTIME in hardware vs software. We have the same issue with the MMU accessed and dirty bits as these can also be implemented either in hardware or in software.

I have spent some time studying the Privileged ISA specification and refer to it frequently. I don’t necessarily agree with all of the choices e.g. regards the choice of level vs edge trigger interrupts for some of the sources, however it is a indeed a necessity for MEIE to be level triggered as the interrupt line is shared. There are different design choices for IPIs and timers, e.g. Intel’s HPET timers for example are configurable as either level or edge triggered. Edge triggered interrupts don’t require poking the hardware to de-assert the interrupt line but they require a dedicated line per source and local acknowledgment.

Michael

--

Sebastian Huber

unread,

Jul 30, 2018, 3:58:52 AM7/30/18

to RISC-V SW Dev, seb...@gmail.com

Am Samstag, 28. Juli 2018 04:07:02 UTC+2 schrieb Paul Miranda:

Is there a spec for the PLIC register set (or any memory mapped register)? Or are they all considered implementation-dependent?

There is a PLIC chapter in The RISC-V Instruction Set Manual, Volume II: Privileged Architecture.

Paul Miranda

unread,

Jul 30, 2018, 11:14:15 AM7/30/18

to Sebastian Huber, RISC-V SW Dev

Yeah it has several references to registers, but none of them are fully defined, at least not in the version I’m looking at from June and I don’t think it’s been updated for many months.

--
You received this message because you are subscribed to a topic in the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/groups.riscv.org/d/topic/sw-dev/BDnxG8643Dc/unsubscribe.
To unsubscribe from this group and all its topics, 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/89164d9f-b2fa-45c7-9a9d-4b516fc4f0ff%40groups.riscv.org.

Michael Clark

unread,

Jul 30, 2018, 12:23:55 PM7/30/18

to Paul Miranda, Sebastian Huber, RISC-V SW Dev

On 31/07/2018, at 3:14 AM, Paul Miranda <paulcm...@gmail.com> wrote:

Yeah it has several references to registers, but none of them are fully defined, at least not in the version I’m looking at from June and I don’t think it’s been updated for many months.

The most detailed description of (a vendor implementation of) the PLIC are in SiFive’s FE310 and U54-MC manuals:

https://www.sifive.com/documentation/chips/freedom-e310-g000-manual/

https://www.sifive.com/documentation/risc-v-core/u54-mc-risc-v-core-ip-manual/

SiFive’s PLIC is implemented in SiFive’s HiFive1, HiFive Unleashed and in the QEMU models of SiFive’s hardware. Spike currently does not have a PLIC.

If a more detailed RISC-V PLIC specification is proposed then it could potentially differ from SiFive’s implementation. There is currently a Fast Interrupts working group where such matters may be discussed.

On Jul 30, 2018, at 2:58 AM, Sebastian Huber <seb...@gmail.com> wrote:

Am Samstag, 28. Juli 2018 04:07:02 UTC+2 schrieb Paul Miranda:
Is there a spec for the PLIC register set (or any memory mapped register)? Or are they all considered implementation-dependent?

There is a PLIC chapter in The RISC-V Instruction Set Manual, Volume II: Privileged Architecture.

--
You received this message because you are subscribed to a topic in the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/groups.riscv.org/d/topic/sw-dev/BDnxG8643Dc/unsubscribe.
To unsubscribe from this group and all its topics, 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/89164d9f-b2fa-45c7-9a9d-4b516fc4f0ff%40groups.riscv.org.

--

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/CC04A8E8-9E78-4623-95EA-A5FB1DC5B554%40gmail.com.

kr...@berkeley.edu

unread,

Jul 30, 2018, 6:32:56 PM7/30/18

to Michael Clark, Paul Miranda, Sebastian Huber, RISC-V SW Dev

>>>>> On Tue, 31 Jul 2018 04:23:11 +1200, "'Michael Clark' via RISC-V SW Dev" <sw-...@groups.riscv.org> said:
[...]

| If a more detailed RISC-V PLIC specification is proposed then it could
| potentially differ from SiFive’s implementation. There is currently a Fast
| Interrupts working group where such matters may be discussed.

[...]

Just to clarify, the fast interrupt task group's CLIC proposal is not
intended to replace the PLIC.

The CLIC is local to one core (or more precisely one hart in current
draft), while the PLIC distributes interrupts across many cores and
feeds in to CLIC.

Krste

Michael Clark

unread,

Jul 31, 2018, 9:12:53 PM7/31/18

to kr...@berkeley.edu, Paul Miranda, Sebastian Huber, RISC-V SW Dev

It’s worth clarifying for those who are not aware of the CLIC vs the PLIC. I didn’t mention the CLIC; which has been the recent focus of the Fast Interrupts Working Group.

The suggestion was that if there was a future proposal for a standard PLIC, that it would be under the Fast Interrupts Working Group?

Reply all

Reply to author

Forward