riscv-fast-interrupt
riscv-fast-interrupt copied to clipboard
riscv
Handling of dereferencing inconsistent with Zc* spec
Zce's table jump instructions (c.jalt and c.jt, see page 68 (JVT CSR) of https://github.com/riscv/riscv-code-size-reduction/blob/master/Zce-release-candidate/Zc.pdf) and the CLIC's hardware vectoring mechanism (see https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#new-xtvec-csr-mode-for-clic) are very similar (they both jump to a pointer obtained from a table).
The retrieval of the pointer from the table however seems to be treated differently in both specifications and it would be nice if this can get aligned.
The Zc* specification states:
The memory pointed to by JVT.base is treated as instruction memory for the purpose of executing table jump instructions.
CLIC's hardware vectoring mechanism specifies the following (see above link):
For permissions-checking purposes, the memory access to retrieve the function pointer for vectoring is treated as a load with the privilege mode (also obeying MPRV and SUM bits) and interrupt level of the interrupt handler.
To me (please correct me if I am wrong) the Zc* specification therefore implies that 'execute permission' is needed to read from anywhere in the jump table, whereas the CLIC specification implies a check with R/W bits (if you have a PMP).
I would greatly prefer if both specifications can get aligned on this (or to hear an explanation why both specifications should differ here).
I prefer the Zc* specification with respect to this topic and I posted the same question as https://github.com/riscv/riscv-code-size-reduction/issues/134 in that task group.
Continuing discussion on the code size version of the issue. https://github.com/riscv/riscv-code-size-reduction/issues/134
TG Meeting 2022/4/12: The inconsistency of NOTE requiring FENCE.I #206 whereas the access was considered a data access was noted. Either this requirement should be dropped (meaning hardware has to fetch from table coherent with data access) or the table access should be treated as an instruction fetch (as in the code size reduction table jump instructions cm.jt and cm.jalt).
Unifying the models between Zce and fast interrupts table lookup should simplify hardware implementations. Table lookups would not be affected by mprv/sum as they are now treated as instruction fetches. Emulation of the table lookup could not use mprv/sum, as that only models load/store permissions not fetch permissions. Modifications to the table would require a FENCE.I.
Hi @kasanovic ,
Unifying the models between Zce and fast interrupts table lookup should simplify hardware implementations. Table lookups would not be affected by mprv/sum as they are now treated as instruction fetches.
I have a question about a use case using both hw vectoring and sw vectoring. Please correct me if I am wrong.
I understand the hw vector fetch requires execute permission now, but seems the sw vectoring still needs read permission for loading. So if some interrupts are configured as hw vectoring, while the rest are configured as sw vectoring, the permission of the vector table has to be set as both read and execute. Otherwise, the management of the interrupts needs to be considered carefully, to make sure there is no overlap between the hw vectoring part and the sw vectoring part.
When hw vector fetch requires read permission, this case is much simpler since the requirement is identical for both hw and sw. I am wondering if CLIC has taken this case info account.
Thanks
Could use a non-normative comment to help explain table permissions settings for one or both of hardware and software vectoring.