From 1b4210ce10c1a97dc11de52ccc8cb1de49a18cac Mon Sep 17 00:00:00 2001
From: dansmathers <63661035+dansmathers@users.noreply.github.com>
Date: Mon, 5 Apr 2021 15:47:45 -0600
Subject: [PATCH] Update clic.adoc

For hardware vectoring access exceptions, both {tval} and {epc} holds the faulting address.  Spec update for issues #111 and #105 (option 2 reasoning)
---
 clic.adoc | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/clic.adoc b/clic.adoc
index b2d6b38..fa045d7 100644
--- a/clic.adoc
+++ b/clic.adoc
@@ -885,14 +885,9 @@ extensions are supported).
 For permissions-checking purposes, the memory access to retrieve the
 function pointer for vectoring is treated as a load with the privilege
 mode and interrupt level of the interrupt handler.  If there is an
-access exception on the table load, {epc} holds the faulting address.
-If this was a page fault, the table load can be resumed by returning
-with {epc} pointing to the table entry and the trap handler mode bit
-set.
-
-Instruction fetch at the handler address might cause misaligned or
-access exceptions, which are reported with {epc} containing the
-faulting instruction fetch address.
+access exception on the table load, both {tval} and {epc} holds the faulting address.
+
+NOTE: Horizontal traps (same privilege level) are unrecoverable. The interesting case is vertical traps, where a more privileged layer is handling page faults or other synchronous faults on vector table access. The regular code path in more privileged layer will want to use xtval to determine what bad virtual address to page in, but will not normally restore xtval when returning to faulting context (potentially after some time and other contexts have run) However, it will restore xepc (using x for more privileged mode here) before using xret on normal code path.  This is a rationale for why both {tval} and {epc} are written with the faulting address.
 
 In CLIC mode, synchronous exception traps always jump to NBASE.