target/riscv: prevent the fence.i from triggering the exception #898
Conversation
On platforms that do not support Zifencei, executing fence.i will trigger an exception, this patch eliminates the impact of the exception Change-Id: I459cff096374064fdb6e18a9d95170510ae1f32e Signed-off-by: Xiang W <[email protected]>
|
please review it @timsifive @TommyMurphyTM1234 |
|
The patch requires progbufsize > 1, is this a issue? |
There was a problem hiding this comment.
Thanks for the patch. I am afraid this is not a proper solution. The exceptions don't trigger in program buffer. There is therefore no reason to change the mtvec. Also, it is not mandatory to have program buffer memory mapped, therefore info->program_address does not have to be a meaningful value.
The exception caused by unsupported fence.i should not have any adverse effect. So there should be no need to handle it in a special way.
I do agree that with the separation of the fences into two program buffer executions. This will make it compatible with targets where progbufsize == 1
why? Can you tell me which spce this information comes from？ |
Alright. It is a bit more general. They don't trigger in debug mode in general. https://github.com/riscv/riscv-debug-spec/blob/master/riscv-debug-stable.pdf its currently on page 50 in section 4.1 |
Thank you! |
|
Don't close this, separating the two fences into two separate program buffer executions is still good and useful as not all targets implementing the program buffer have to have a progbufsize > 1 |
On platforms that do not support Zifencei, executing fence.i will trigger an exception, this patch eliminates the impact of the exception
Change-Id: I459cff096374064fdb6e18a9d95170510ae1f32e