search

riscv / riscv-fast-interrupt

Proposal for a RISC-V Core-Local Interrupt Controller (CLIC)
https://jira.riscv.org/browse/RVG-63
Creative Commons Attribution 4.0 International
245 stars 49 forks source link

Clarify changes to CLIC memory-mapped registers #304

Closed JamesKenneyImperas closed 1 year ago

JamesKenneyImperas commented 1 year ago

I've got some questions about the recent changes to the CLIC memory-mapped register definition. Can you help?

In section 4.1.1 (CLIC Memory Map), talking about M-mode, it still says this:

The intent is that only the necessary address regions are made accessible to each privilege mode using the system’s standard memory protection mechanisms. This can be done either using PMPs in microcontroller systems, or page tables (and/or PMPs) in harts with virtual memory support.

The CLIC specification does not dictate how CLIC memory-mapped registers are split between privilege regions as well as the layout of multiple harts as this is generally a platform issue and each platform needs to define a discovery mechanism to determine the memory map locations. Some considerations for platforms to consider are selecting regions that allow for efficient PMP and virtual memory configuration. For example, it may desired that the bases of each privilege mode CLIC region is VM page (4k) aligned so they can be mapped through the TLBs.

I think it would be worth reworking these two paragraphs in the light of the other changes here. The first paragraph above is talking about "each privilege mode", but now all memory-mapped registers here are relevant to M-mode only, aren't they? In the same way, the second paragraph is talking about memory-mapped registers split between privilege regions. It feels like these two paragraphs are a bit stale and reflecting an earlier implementation.

Moving on to section 5.1.1. (ssclic CLIC Memory Map), it says:

It is not intended that the interconnect to the CLIC memory-mapped interrupt regions be required to carry the privilege mode of the initiator. A possible implementation of the CLIC memory map would be to alias the same physical CLIC memory-mapped registers to different address ranges, with each address range given different permissions for each privilege mode. Interrupts configured as M-mode interrupts appear as hard-wired zeros in the S-mode address range.

Given that each privilege level now has its own cliccfg register, is the second statement about aliasing still true? If this was done, the cliccfg registers would not be independent.

There are also inconsistencies between M-mode, S-mode and U-mode definitions. For S-mode and U-mode, it states the blocks must be aligned to 4k boundaries. For M-mode, this is an option but not mandated. Is this inconsistency intentional?

Thanks.

JamesKenneyImperas commented 1 year ago

Additionally, can you please clarify the behavior of the xcliccfg.nlbits fields; specifically:

  1. Are xcliccfg.nlbits fields independent of each other, or are they aliases of the same thing? and:
  2. If xcliccfg.nlbits fields are independent, is it the case that mcliccfg.nlbits is used to determine the level of interrupts targeting M-mode, scliccfg.nlbits is used to determine the level of interrupts targeting S-mode and ucliccfg.nlbits is used to determine the level of interrupts targeting U-mode?

Thanks.

dansmathers commented 1 year ago

notes from TG meeting 2/28/23: will split into 2 issues to separate cliccfg.nlbits question (issue #311). will try to re-write how mem-mapped registers . platform can mandate to 4k boundaries if it is virtual memory but spec can leave it open. use same language as in m-mode. for cliccfg could put fields in different places in the word. put in one word with the byte for each priv mode. high byte is m mode, low byte is u-mode. byte 1 is s-mode.

dansmathers commented 1 year ago

closed with pull #312 and text updates