It's already used: https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#44-new-xtvec-csr-mode-for-clic

Are we going to use bit1 soon in the future? We are wondering if we can use bit1 to indicate there’s illegal value (WLRL) – if bit1 is written with 1 then fire exception.

 

From: <tech-privileged@...> on behalf of Andrew Waterman <andrew@...>
Date: Friday, June 19, 2020 at 9:37 AM
To: Joe Xie <joxie@...>
Cc: "tech-privileged@..." <tech-privileged@...>, "James Xu (SW-GPU)" <jamesx@...>, Lucien Dunning <ldunning@...>
Subject: Re: [RISC-V] [tech-privileged] mtvec question

 

External email: Use caution opening links or attachments

 

I have been bitten by this, too, but I have little in the way of advice.

 

There are various software approaches to reduce the likelihood of encountering this problem, even if the programmer forgets to insert the alignment directive.  The first one that comes to mind is to put a trap handler in its own ELF section so that the linker script can forcibly align them.

Unfortunately, sometimes the best you can do with these nitty-gritty low-level systems programming issues is: "don't fuck up".  Debugging them is inherently painful.

 

On Thu, Jun 18, 2020 at 6:22 PM Joe Xie <joxie@...> wrote:

Hi Andrew, all,

 

The current priv spec reserves lower 2bits of mtvec (ad stvec) to indicate vectored interrupts, there’s an issue that if exception handler is word aligned but SW mis-program the lower 2bits to be non-0 value, it is still a valid value.

 

So now exception will start from an incorrect PC, and depending on the instruction word on that address you will see weird behaviors or the core will just fall into infinite loop. It is very annoying to debug this kind of issue.

 

Any advice on how to overcome the issue other than SW check?