Access to reserved address space

[divan0v]

Clarify, please, expected behaviour on access to reserved address space (0x0008-0x003F, 0x00C0-0x07FF) and for custom address space (0x0800-0x0FFF) in memory map:

1. Access fault or hardwired zero (when access from X-mode to X-mode layout for reserved/custom address)?
2. Do I understand correctly that access from S-mode to any address in M-mode layout (including reserved/custom address space) raises access fault?

Thanks

[dansmathers]

For 1: Good point. We will discuss in a TG meeting. I expect that reserved address space means that future clic spec extensions might use that space but I would think there is no requirement of values returned. But I agree we should compare how the word reserved is already used in other RISC-V specs and see if that matches what is intended.

for 2: The clic spec does say 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.

So the clic implementation itself isn't required to generate access faults but the clic design is intended to be compatible with existing memory protection mechanisms to accomplish s-mode to m-mode protection.

[divan0v]

For 2: Is clic implementation (that generates such access fault) compatible with specification (isn't required but is allowed)?

[divan0v]

I doubt a little bit. Could I ask separate additional question. Is required to raise exception for access from S/U mode to clicfg/clicinfo/clicinttrig? Or behaviour not distinguished and should be same as for access to reserved/custom space as disscussed above?

[dansmathers]

Here are my notes from the TG meeting 3/29/2022: not going to require reserved does anything. don’t put anything there. It might get stomped on. (use custom regions for custom features). if you don’t have something there what do you do? because it is reserved, any kind of trap is ok. reserved addresses might not be elsewhere in riscv specs. don’t want to require a trap. if clicv2 uses it and clicv1 traps, clicv1 is incompatible. up to platform to decide what happens. So generating faults is allowed but not required. create pull to clean up text to clarify.

[divan0v]

Thanks, i just explored notes. If I understand correctly, then straightforward implementation has no traps when access from any mode to custom/reserved space to be compatible with clicv2, i.e. hardwired to zero, for example. But what behaviour is expected for access from S/U mode to required by clicv1 specification registers cliccfg/clicinfo/clicinttrig?

[kasanovic]

For reserved memory regions, we do not specify any specific trap behavior. Depending on system bus architecture, the system can ignore the access (e.g., read zero/write ignored) or cause a bus error (usually imprecise interrupt), or some other platform-specific behavior. The "reserved" annotation here implies that future standards might place additional standard registers in that space, and so using the space for non-standard features is inadvisable.

[kasanovic]

Closed by #243