In the sections covering traps, best highlighted by Hypervisor Mode, is a bit of a conundrum.
As it stands, following the lead of ECALL and the convention of the trap being responsible for performing the context switch "by hand", using mscratch, sscratch or hscratch to do so, Hypervisor trap vectors would be executed in the FOREIGN architecture opcode space (hence the reason for a permutation of mtvec / stvec / htvec tables, one for each separate incompatible namespace).
The problem is the changeover point from the foreign namespace on change of the CSR to a "safe" namespace from which the "common" trap subroutine is called, and, more than that, the return from that subroutine also has to pop the CSR from a stack in a foreign arch!
Can anyone help think this through properly or think of better solutions?
Execution of foreign archs in hypervisor mode is an extreme case that, if solved, would mean that supervisor mode was also much easier to think through.
L.
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/8e01acb4-a263-401d-9472-c54bb185ad05%40groups.riscv.org.
I think that having a per-priv-level last-isans and trap-isans csrs would work. on taking a trap/syscall/interrupt the current isans would be saved in the last-isans of the new priv-level and the current isans would be set to the new priv-level's last-isans. on a return from the trap, the current isans would be set to last-isans for the old priv-level.
If support for per-trap isans values is needed,
then there can be a per-priv-level trap-isans vector, similar to the trap-entry-point vectors, but the vector base address is specified in a different CSR.
On Wed, Jun 12, 2019, 23:30 lkcl <luke.l...@gmail.com> wrote:
https://libre-riscv.org/isa_conflict_resolution/isamux_isans/
In the sections covering traps, best highlighted by Hypervisor Mode, is a bit of a conundrum.
As it stands, following the lead of ECALL and the convention of the trap being responsible for performing the context switch "by hand", using mscratch, sscratch or hscratch to do so, Hypervisor trap vectors would be executed in the FOREIGN architecture opcode space (hence the reason for a permutation of mtvec / stvec / htvec tables, one for each separate incompatible namespace).
The problem is the changeover point from the foreign namespace on change of the CSR to a "safe" namespace from which the "common" trap subroutine is called, and, more than that, the return from that subroutine also has to pop the CSR from a stack in a foreign arch!
Can anyone help think this through properly or think of better solutions?
Execution of foreign archs in hypervisor mode is an extreme case that, if solved, would mean that supervisor mode was also much easier to think through.
L.
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
On Thursday, June 13, 2019, Jacob Lifshay <program...@gmail.com> wrote:I think that having a per-priv-level last-isans and trap-isans csrs would work. on taking a trap/syscall/interrupt the current isans would be saved in the last-isans of the new priv-level and the current isans would be set to the new priv-level's last-isans. on a return from the trap, the current isans would be set to last-isans for the old priv-level.Hmm.... this is close to the concept of the last-isans being the top of the stack, and as such, would need to be thought through very carefully when it comes to supervisor and hypervisor modes, when recursion may be involved.Also not yet thought through: normally, attempting to read a priv CSR from one mode actually gives the CSR from another mode, I forget which ones.The ISAMUX/NS CSR may need the same rules applied, so if software tries to read or set the M Mode CSR the S Mode one is set/returned instead, something like that.If context switching latency really is a performance issue the last-isans concept would indeed help.If support for per-trap isans values is needed,Per permutation of isans possibilities/combinations, yes. Per trap I do not believe so.
then there can be a per-priv-level trap-isans vector, similar to the trap-entry-point vectors, but the vector base address is specified in a different CSR.
Hmmm... yuk. Given that the vector would need to be written to, it would cause a memory write at the point of the exception.
What is the use case for having xtisansvec (a per xcause lookup table) that allows each trap vector to execute in a *separate* RISCV namespace?(you can tell that I think one trap-isans is enough, per priv level, however there may actually be a genuine use case. If so, I'd like to hear what it is)the reason I originally had was orthogonality.
one (admittedly pretty contrived) use case two different legacy proprietary user-space libraries that sets some interrupt handlers and only supports mutually exclusive isans settings.
The important parts are still there if trap_base_isans is removed. if trap_base_isans is desired, it can be added back in in a backward compatible way split out in another extension, rather than the base isans extension.
On Friday, June 14, 2019, Jacob Lifshay <program...@gmail.com> wrote:What is the use case for having xtisansvec (a per xcause lookup table) that allows each trap vector to execute in a *separate* RISCV namespace?(you can tell that I think one trap-isans is enough, per priv level, however there may actually be a genuine use case. If so, I'd like to hear what it is)the reason I originally had was orthogonality.As good a reason as any :)one (admittedly pretty contrived) use case two different legacy proprietary user-space libraries that sets some interrupt handlers and only supports mutually exclusive isans settings.Here, if TRAPISANS is set to the preferred (global) default, in that (default) assembly code, one of them may work out which actually needs calling and treat the other as a subroutine. ISANS for the appropriate NS being set before call and restored afterwards.If both are binary and the source code lost or not available, both legacy subroutines may be treated in the same fashion by an "actual" trap handler that, once again, runs in the default TRAPISANS.
The important parts are still there if trap_base_isans is removed. if trap_base_isans is desired, it can be added back in in a backward compatible way split out in another extension, rather than the base isans extension.Yyyeah that sounds reasonable.
L.
reviewing https://libre-riscv.org/isa_conflict_resolution/isamux_isans/#privtrapsin the priv-traps section, I don't think the trap/xRET functionality should be conditional on isans matching anything, as that makes the HW unnecessarily more complicated and the operations harder to understand.
unrelated note: there is no instruction named xret, xRET is shorthand for one of URET, SRET, MRET, or HRET (if that ever becomes a thing).
On Friday, June 14, 2019, Jacob Lifshay <program...@gmail.com> wrote:reviewing https://libre-riscv.org/isa_conflict_resolution/isamux_isans/#privtrapsin the priv-traps section, I don't think the trap/xRET functionality should be conditional on isans matching anything, as that makes the HW unnecessarily more complicated and the operations harder to understand.Was thinking if it made any difference... it is just setting to a value that it's already set to, isn't it?
unrelated note: there is no instruction named xret, xRET is shorthand for one of URET, SRET, MRET, or HRET (if that ever becomes a thing).Yes. Thought that was a well known convention.
L.
maybe trap_base_isans can be included but allowed to be hardwired to 0, leaving essentially the same implementation as removing trap_base_isans.