allenjbaum
commented
12 hours ago I just wrote a screed about that in a different context. I would not take this as gospel One part of that is whether the trap was caused by an interrupt or an exception.
Generally, an interrupt is asynchronous: it is unrelated to any code that is interrupted; it generally happens between instructions. (I'm not sure if there are specific exceptions (sic) to that, e.g. some very long running instructions like matrix multiply, or push/pop)
The only way I think an interrupt could be imprecise is if you couldn't return to the code with hart state such that all instructions previous to the trap point have retired, and all subsequent have not.
I would consider imprecise exceptions to include the above condition, but also when exception state does not allow the determination of the instruction that caused the trap. E.g.
- xepc doesn't point to the instruction that caused the exception,
- xtval not having a (useful) value (excepting the value 0, which is
specifically allowed),
- xcause ambiguous, etc
RISC-V has imprecise exceptions based on this definition, e.g. cases where the instruction that has trapped must to be restarted from the beginning, but registers or memory have been updated. That may not matter if the memory that was updated is idempotent (and the spec does call that out, and advises to not use the op on non-idempotent memory).
This came up in the context of decode errors on MMIO devices and memory ordering. A device may have 4K of address space allocated to it (for MMU protection purposes) but only populate a few bytes. An implementation can choose to ignore, alias, or report an error if an unpopulated region is accessed. It may take 100's of cycles for an error response to return to the requestor, and if the requestor has continued to execute code, When that error response comes back... what should it do? One answer is don't do that; never allow more than one outstanding request to a device address. That's a performance killer. Another is to ensure that code after that is marked speculative and roll back state changes. That may work for high end cores, but not otherwise in-order cores. One other is to signal the core with an exception or trap. This is either a very imprecise exception, or an imprecise interrupt, but which?
On Fri, Nov 15, 2024 at 1:49 AM Tim Hutt @.***> wrote:
The spec talks in 3 places about exceptions being "precise" or "imprecise":
The EEI defines for each trap whether it is handled precisely, though the recommendation is to maintain preciseness where possible. Contained and requested traps can be observed to be imprecise by software inside the execution environment. Invisible traps, by definition, cannot be observed to be precise or imprecise by software running inside the execution environment. Fatal traps can be observed to be imprecise by software running inside the execution environment, if known-errorful instructions do not cause immediate termination. https://riscv-specs.timhutt.co.uk/spec/20240411/unpriv-isa-asciidoc.html#_exception_handling:~:text=The%20EEI%20defines,cause%20immediate%20termination.
To aid in system debugging, we strongly recommend that, where possible, RISC-V processors precisely trap physical memory accesses that fail PMA checks. Precisely trapped PMA violations manifest as instruction, load, or store access-fault exceptions, distinct from virtual-memory page-fault exceptions. Precise PMA traps might not always be possible, for example, when probing a legacy bus architecture that uses access failures as part of the discovery mechanism. In this case, error responses from peripheral devices will be reported as imprecise bus-error interrupts. https://riscv-specs.timhutt.co.uk/spec/20240411/priv-isa-asciidoc.html#scause:~:text=To%20aid%20in,bus%2Derror%20interrupts.
PMP violations are always trapped precisely at the processor. https://riscv-specs.timhutt.co.uk/spec/20240411/priv-isa-asciidoc.html#scause:~:text=PMP%20violations%20are%20always%20trapped%20precisely%20at%20the%20processor.
However:
- There's no definition of what "precise" and "imprecise" mean.
- It doesn't describe what effect imprecise traps should have.
I think there's a lot of detail missing here. I assume the ARM spec (or maybe MIPS?) explains all of this and it's just assumed knowledge, but I'm not familiar with ARM or MIPS & I think the RISC-V spec shouldn't assume I am.
— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/1728, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJVXZJYYCTYYI363QD32AW7SJAVCNFSM6AAAAABR2Z43PGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY3DCNBVGA3TQMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
The spec talks in 3 places about exceptions being "precise" or "imprecise":
However:
I think there's a lot of detail missing here. I assume the ARM spec (or maybe MIPS?) explains all of this and it's just assumed knowledge, but I'm not familiar with ARM or MIPS & I think the RISC-V spec shouldn't assume I am.