Zcmt: clarify translation of jvt-based addresses in M-mode

[Wren6991]

The latest draft says this about jvt (and this seems to match the ratified PDF from the riscv-code-size-reduction repo):

jvt.base is a virtual address, whenever virtual memory is enabled.

The memory pointed to by jvt.base is treated as instruction memory for the purpose of executing table jump instructions, implying execute access permission.

The first paragraph seems ambiguous, because virtual memory is "enabled" separately for fetch and load/store/AMO. The second paragraph is a good hint but it's not clear whether this is describing the translation or just X permissions (including PMP).

My question is: are jvt-based accesses translated in M-mode when mstatus.mprv is set and mstatus.mpp = S? If the intent is this is not translated then the first quoted sentence might be written more explicitly like so:

jvt.base is a virtual address, whenever virtual memory is enabled for instruction fetch. This includes S-mode execution when satp.mode is nonzero, and excludes all M-mode execution.

This is relevant because M-mode routines manipulating S-mode memory may also be compiled with Zcmt jumps, using an M-mode-supplied jvt value.

[aswaterman]

I think the description could be worded more artfully, but the answer to your question is unambiguous, because MPRV is defined to affect only explicit memory accesses.

[Wren6991]

Thank you for the definitive answer, that clears up my question nicely.

I think the description could be worded more artfully, but the answer to your question is unambiguous, because MPRV is defined to affect only explicit memory accesses.

Thanks, I went looking for that definition of MPRV, because that is a highly useful distinction and covers this neatly. The nearest I could find was this table caption in the section on the hypervisor extension:

Table 32. Effect of MPRV on the translation and protection of explicit memory accesses

If MPRV only affects explicit accesses (and not implicit ones) then would it be possible to add words to that effect to the documentation of mstatus in the section on the machine ISA? That documentation mentions load/stores (positively) and instruction fetch (negatively), but jvt-based implicit accesses are neither of those things.

The machine ISA description I'm referring to is 3.1.6.4:

The MPRV (Modify PRiVilege) bit modifies the effective privilege mode, i.e., the privilege level at which loads and stores execute. When MPRV=0, loads and stores behave as normal, using the translation and protection mechanisms of the current privilege mode. When MPRV=1, load and store memory addresses are translated and protected, and endianness is applied, as though the current privilege mode were set to MPP. Instruction address-translation and protection are unaffected by the setting of MPRV. MPRV is read-only 0 if U-mode is not supported.

[aswaterman]

The Zcmt spec makes it clear that JVT accesses are considered implicit accesses.

We can't aggregate this information in one place because it would make the spec unscalable. The scalable approach is to define common terminology, then use that terminology in the extension specs. And that's exactly what we've done in this case.

[Wren6991]

The Zcmt spec makes it clear that JVT accesses are considered implicit accesses.

Agreed, this part is clear. I think the explicit/implicit distinction is a nice cut point and these terms are well defined. I don't see any reference to explicit/implicit accesses in the definition of mstatus.mprv in 3.1.6.4, and it would be useful for me as a reader if it built on those common terms.

[aswaterman]

The MPRV section was written before the explicit/implicit concept was defined, but you can read that section's use of the phrase "loads and stores" to mean the same thing as "explicit memory accesses". We'll get around to fixing it eventually, but for the moment, there's no ambiguity: "loads and stores" obviously excludes implicit memory accesses.