smclicshv - Software vectoring only allowed when hardware vectoring is disabled?

[jgonion]

Shouldn't the HW & SW vectoring schemes be consistent?

The avoidance of context save/restore at the start/end of interrupt handlers is valuable regardless of whether hardware vectoring is enabled or not.

Currently, mnxti only allows software vectoring wwhen hardware vectoring is disabled (clicintattr.shv == 0)

[dansmathers]

7.2.5. smclicshv Changes to Next Interrupt Handler Address and Interrupt-Enable CSRs (xnxti)
adds the following requirement to xnxti csr: we will discuss this in TG.

&& (clicintattr.shv==0) ) {
// There is an available, non-hardware-vectored interrupt.

[kasanovic]

This is to allow hardware and software handlers to have different software interfaces. The assumption is that hardware vectoring would have customized save/restore, whereas the software vectoring uses a generic save/restore. We are not sure if this might not break some assumption that hardware handlers would rely on. Will continue discussion.

[efoster029]

The real problem is the smclicshv extension currently only allows software or hardware vectoring, not both, which is a shame.

If hardware vectoring used XTVEC and software vectoring used MTVT, both hardware and software vectoring could live harmoniously, giving RISC-V the best of both worlds: Hardware vectoring for higher priorities avoiding the overhead of software dispatch, and software vectoring horizontal priorities, avoiding the overhead of unnecessary context save/resore.

The current definition allows us to select between two unwanted taxes: People either need to pay the extra overhead of software getting involved in every interrupt dispatch (SHV=0), or they have to pay the tax of unnecessary context save/restore (SHV=1).

If we use XTVEC for hardware vectoring (as RISC-V intends) and XTVT for horizontal software vectoring, everything just works, and we would have a fundamentally more capable platform, that has distinct interfaces for HW vs SW vectoring while also allowing both to co-exist.

[kasanovic]

In current design, individual interrupts can be selected to be vectored in hardware or software (setting of clicintattr.shv), so we're unclear what is meant by "currently only allows software or hardware vectoring, not both" in issue above.

The same xtvt table is used for both software and hardware vectoring, but the software handler is located at xtvec.

In current design, xtvec points at instructions (as with CLINT style interrupts and regular RISC-V exceptions), whereas xtvt points at table entries containing function pointers. xtvec is where the software handler is located, and xtvec is also used for exception handlers so cannot be repurposed for a software vectoring table.

In another reading of your issue, it may be that you are requesting that a single interrupt handler can be called in two ways. 1), if there is no software handler running, call the full handler using the hardware vectoring, which will incur the full context save/restore code. 2) If a software handler is running and has already saved context, call a smaller handler that does not handle save/restore. This would require a different function to be called for each scenario, as the save/restore code is typically scheduled around other operations in the handler. This would space for the second pointer. Also, the processor would have to informed via some state bits set by some instruction which of the two functions to call.

One possible way to achieve this is to double the size of the xtvt table with even/odd entries, where the even entries are streamlined handlers without save/restore code, while odd entries are full hardware handlers with save/restore code. We'd have to add extra state bit to disable SHV, which would be set at instruction 10 in C-ABI handler loop. When SHV is disabled mnxti returns the even entry corresponding to the interrupt, and calls into the streamlined handler. The mnxti instruction (12) would also reenable SHV.

[kasanovic]

After further discussion in task group meeting 8/1/23, we are going to explore a scheme that only requires a single table entry for each handler, and which doesn't duplicate code between hardware and software versions of the handler. This might not support the "interrupt attribute" form of hardware vectored handler, or might required additional state bits to support that as an option.

[dansmathers]

Notes from TG meeting:
The idea is there is only a single static code body and somehow have mechanism, if have hw vectored outside of this. so only need one entry in the table if we can engineer this. if in service loop, don’t do save restore of hardware vectored interrupts. otherwise do save restore. like set a bit in csr and test it. it assumes all hw are using the same abi model. so don’t need twice the table entries and don’t need twice the static code.

How about a new CSR OFFSET_TO_SKIP_SHV_CONTEXT_SAVE (need a better name) that contains a programmable address offset so hw vector behaves as:

pc := (OFFSET_TO_SKIP_SHV_CONTEXT_SAVE + M[TBASE + XLEN/8 * exccode]) & ~1

Can keep to 0 (or hardwired to 0 if not supported) but when in service loop, set this CSR to non-zero. When 0, hardware vector jumps to address indicated in the vector table which will do the necessary context save. when non-zero hardware jumps to address indicated in the vector table plus an offset to bypass context save because software is already in an interrupt handler with context saved.

[dansmathers]

TG discussion 12/5/2023 - Can it be derived from context from bits we are already changing? e.g. if interrupt level is non-zero. maybe that works? global mode setting to operate that way or not. so don’t need to do anything in the code. if interrupt level is 0, need to save/restore. if interrupt is non-zero, skip save/restore.
worried about code explosion from every handler having save restore code. maybe 16-byte offset in tvt? jumping to common base address for isolated interrupt which does save, does mxnti at that point? restore also has to happen properly. so basically a single tvt with isolated interrupt. must be a solution. keep thinking about.

[dansmathers]

closed by #370