From 22d631403a82b496f6a185a2cf5bb64b40d675d3 Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 13 Jun 2019 07:10:42 +0100 Subject: [PATCH] --- isa_conflict_resolution/isamux_isans.mdwn | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/isa_conflict_resolution/isamux_isans.mdwn b/isa_conflict_resolution/isamux_isans.mdwn index 7522c5eea..337998857 100644 --- a/isa_conflict_resolution/isamux_isans.mdwn +++ b/isa_conflict_resolution/isamux_isans.mdwn @@ -208,12 +208,10 @@ Support for both assembly languages immediately after the CSR write is clearly i # Is it strictly necessary for foreign archs to switch back? -It is not strictly necessary for foreign archs to have an equivalent of the CSR ISAMUX/NS write, although it is optional for them to do so. - -The reason is that this is a RISCV proposal, not a MIPS or x86 proposal. - -The test case is hypervisor mode. Running the hypervisor core in x86 or MIPS assembly on a RISCV system makes no sense. The RISCV hypervisor may take care transparently of running foreign arch OSes - unmodified - even just as Qemu KVM Mode does if the implementation fully supported x86 assembler. That code has no need to know it is a guest under a hypervisor. - +Yes because trap vectors execute in the *current* namespace, and as described above, the first thing that they are expected to do under normal circumstances is to change the CSR ISAMUX/NS back to a known-good (RV) value, push the old value onto the stack, and to call the equivalent RV trap vector as a subroutine. +The foreign arch therefore has to have some mechanism of returning to RV mode: one of the simplest ways is to memory map the NS CSR. +Foreign arch trap vectors are extremely weird in that the setting of the CSR is handled through the foreign arch instruction set, however the code following that instruction will be an RV opcode! +More thought on this is required. -- 2.30.2