Solidify description of how tval is populated on EBREAK (riscv#2136)

We tried to fix this in riscv#601, but the text doesn't quite cover the
intended case, because the breakpoint exception does not occur on
a fetch, load, or store: it occurs as a result of executing a
non-memory instruction.  Fix by listing this case explicitly.

Author: aswaterman

src/machine.adoc

@@ -1990,6 +1990,14 @@ occurs on an
 instruction fetch, load, or store, then `mtval` will contain the
 faulting virtual address.
 
+On a breakpoint exception raised by an EBREAK or C.EBREAK instruction, `mtval`
+is written with either zero or the virtual address of the instruction.
+
+NOTE: For breakpoint exceptions raised by [C.]EBREAK, the virtual address of
+the instruction is already recorded in `mepc`.
+Recording the same address in `mtval` is redundant; the option is provided for
+backwards compatibility.
+
 When page-based virtual memory is enabled, `mtval` is written with the
 faulting virtual address, even for physical-memory access-fault
 exceptions. This design reduces datapath cost for most implementations,

src/supervisor.adoc

@@ -673,6 +673,9 @@ occurs on an
 instruction fetch, load, or store, then `stval` will contain the
 faulting virtual address.
 
+On a breakpoint exception raised by an EBREAK or C.EBREAK instruction, `stval`
+is written with either zero or the virtual address of the instruction.
+
 [[stvalreg]]
 .Supervisor Trap Value register.
 include::images/bytefield/stvalreg.edn[]