Specify what imprecise traps are #1728
Comments
|
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:
1. There's no definition of what "precise" and "imprecise" mean.
2. 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
<#1728>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJVXZJYYCTYYI363QD32AW7SJAVCNFSM6AAAAABR2Z43PGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY3DCNBVGA3TQMA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Yeah vector instructions can be interrupted mid-instruction. There's a mechanism to resume them from the middle (
I think this is referred to as a "resumable" trap in a number of places. Is there a definition of precise/imprecise we can lift from somewhere else? |
|
This just came up in a meeting today, and it was basically my definition:
no instruction past the instruction that caused the trap will retire, and
all instructions prior to it will retire.
Note that there are cases where speculation may cause state to be updated,
specifically A-bit setting in PTE entries can occur even if the instruction
nerve completrs.
I'm not sure if there is something similar in FS/VS bits instatus.
…On Sat, Nov 16, 2024 at 3:54 AM Tim Hutt ***@***.***> wrote:
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
Yeah vector instructions can be interrupted mid-instruction. There's a
mechanism to resume them from the middle (vstart).
but also when exception state does not allow the determination of the
instruction that caused the trap
I think this is referred to as a "resumable" trap in a number of places.
Is there a definition of precise/imprecise we can lift from somewhere else?
—
Reply to this email directly, view it on GitHub
<#1728 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJSM3CJDXIZ2FD2HN7T2A4XA7AVCNFSM6AAAAABR2Z43PGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBQGUZTKNRZHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I would still have many questions about that definition, e.g:
Maybe the definition could be something like this:
(I'm sure this is wrong but we have to start somewhere.) |
Loads (and other instructions) in the V extension may update multiple registers. A trap (e.g. page fault or interrupt) may happen in the middle, allowing a subset of the registers to be updated or even a partial update of a single register. See the description of the vstart CSR in the unprivileged spec. |
|
A misaligned store can write to either half, and then take an exception....
…On Tue, Nov 19, 2024 at 3:30 PM Paul Donahue ***@***.***> wrote:
Are instructions allowed to have partial effect? Sounds like yes from your
PTE example, but what are the limits of this? Can an instruction that
writes to two registers just write to one of them?
Loads (and other instructions) in the V extension may update multiple
registers. A trap (e.g. page fault or interrupt) may happen in the middle,
allowing a subset of the registers to be updated or even a partial update
of a single register. See the description of the vstart CSR in the
unprivileged spec.
—
Reply to this email directly, view it on GitHub
<#1728 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJV2PDWC4B3FEZXVPRL2BPC2JAVCNFSM6AAAAABR2Z43PGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWHE3TGOJSGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Ok so:
|
|
On Wed, Nov 20, 2024 at 12:15 PM Tim Hutt ***@***.***> wrote:
4. xtval contains the instruction bits (optionally).—
It isn't just instruction (==opcode) bits; it is usually a virtual address;
only illegal instruction exception puts opcode bits into tval.
(I don't recall if any newer extension mandates anything else, e.g.
software /hardware error exceptions.
Message ID: ***@***.***>
… |
Both the A bit and FS/VS bits, if implemented imprecisely (different type of "precise"), can be updated at any time for any reason. The imprecise bit update isn't architecturally tied to any instruction. So, for this discussion of "precise exceptions," they don't matter. Note that the vector spec does have a nice definition of a precise vector exception. If you take away the vector-specific stuff, it says the two conditions from above (which match Allen's original defintion):
I don't think Tim's conditions 3 and 4 are needed; even imprecise traps have to write mepc/mtval with the exceptional instruction information So, my take is that a precise trap is one where:
|
|
@dhower-qc definition is consistent with my understanding of the term. |
|
Precise traps can refer to precise exception traps, or precise interrupt
traps.,
In both cases, EPC has to point to an instruction where all ops prior have
retired, and neither the instruction pointed nor any after have retired.
Precise exception have an additional requirement, that EPC points to the
instruction that directly caused the interrupt.
Bus Errors are interrupts rather than exceptions because EPC doesn't point
to that instruction.
But other trap CSR values must not have an incorrect value, e.g. TVAL must
be zero (as I read the spec), and xCause must not alias to some other
interrupt cause type.
…On Thu, Nov 21, 2024 at 8:13 PM Derek Hower ***@***.***> wrote:
Note that there are cases where speculation may cause state to be updated,
specifically A-bit setting in PTE entries can occur even if the instruction
nerve completrs.
I'm not sure if there is something similar in FS/VS bits instatus.
Both the A bit and FS/VS bits, if implemented imprecisely (different type
of "precise"), can be updated at any time for any reason. The imprecise bit
update isn't architecturally tied to any instruction. So, for this
discussion of "precise exceptions," they don't matter.
Note that the vector spec does have a nice definition of a precise vector
exception. If you take away the vector-specific stuff, it says the two
conditions from above (which match Allen's original defintion):
1.
all instructions older than the trapping vector instruction have
committed their results
2.
no instructions newer than the trapping vector instruction have
altered architectural state
I don't think Tim's conditions 3 and 4 are needed; even imprecise traps
have to write mepc/mtval with the exceptional instruction information
So, my take is that a precise trap is one where:
1. all instructions older than the trapping instruction have committed
their results
2. no instructions newer than the trapping instruction have altered
architectural state
—
Reply to this email directly, view it on GitHub
<#1728 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJQM55PV2FBDUMGXMZD2B2VPVAVCNFSM6AAAAABR2Z43PGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJSHA2DANZVG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: