is MTVEC a really necessary CSR

[xhayd]

Hello Everyone !!

I have been going through the privileged spec v1.9.1 and have this doubt popped up, is the MTVEC CSR register really necessary. By that what I intend to ask is, it says in the definition of the MTVEC register that it holds the base address of the M mode trap vector. What exactly is this M mode trap vector here. I have an understanding that a trap is a software invoked interrupt by a programmer (please let me know if I`am wrong here) . I saw that the
MCAUSE register keeps track of the interrupts and the exceptions that occur by flashing specific codes in the MCAUSE register and the MBADADDR holds the faulting address (under the 3 or 4 specific conditions as per the spec) and MEPC holds the virtual address of the instruction that caused the exception. Now if a trap occurs then the MTVEC which is (somehow by some other mechanism) holding the M mode trap handler`s address is fed to the fetch unit so that the fetching should now start from that address (is this understanding correct).

My queries:: lets say a cpu boots in machine mode and a mode change occurs to User mode, now what happens if a trap or exception or interrupt occurs in User mode how is this handled

Given the fact that a cpu supports machine and user privilege modes is the scenario mentioned above a valid case

How does the privilege mode change occur is it done under software control? if yes then any specific instruction that does this ? or it is done under hardware control.

Also what would be a scenario where a machine mode trap would occur?

Thanks !!

[Paolo Bonzini]

On 27/04/2017 09:52, xhayd wrote:
> Also what would be a scenario where a machine mode trap would occur?

All traps go to machine mode, unless machine mode explicitly delegates
them to supervisor mode.

Thanks,

Paolo

[xhayd]

Ok so even in the case of a CPU which supports only Machine and User mode and a user mode code is running , in the event of a trap, the privilege mode change occurs and the trap is handled in machine mode. OK Thanks Paolo I got this part.

Now how do the privilege modes change from M -> U and U -> M for example.

Thanks

[Bruce Hoult]

On Thu, Apr 27, 2017 at 11:12 AM, xhayd <xha...@gmail.com> wrote:

Ok so even in the case of a CPU which supports only Machine and User mode and a user mode code is running , in the event of a trap, the privilege mode change occurs and the trap is handled in machine mode. OK Thanks Paolo I got this part.

Now how do the privilege modes change from M -> U and U -> M for example.

As on every common modern machine:

U -> M: on a page fault, unaligned address, divide by zero etc, or explicit syscall/svc/sw interrupt instruction. Or hardware interrupt.

M -> U: on a "return from interrupt" instruction where the saved processor status indicates the CPU should be in U mode.

 

[Michael Clark]

On 27 Apr 2017, at 8:12 PM, xhayd <xha...@gmail.com> wrote:

Ok so even in the case of a CPU which supports only Machine and User mode and a user mode code is running , in the event of a trap, the privilege mode change occurs and the trap is handled in machine mode. OK Thanks Paolo I got this part.

Now how do the privilege modes change from M -> U and U -> M for example.

If there is a synchronous exception (load or store access fault, misaligned address, illegal instruction, etc) or asynchronous exception (timer, software or external interrupt) when the processor is in U mode, the mode will be switched based on the delegation registers (medeleg/mideleg) for the specific trap cause and the processor will jump to the address held in mtvec (which can in some cases be a hardwired address). mstatus.mpp is set to the last operating mode e.g. U mode if that is the mode the processor was in when the trap occured to be used later when returning from the trap. This is how the processor transitions from U mode to M mode.

Once the M mode software (or S mode in the case the exception has been delegated), has handled the exception by inspecting mcause, mbadaddr, and mepc, the M mode software can then take some action and set mepc (for example to advance past an illegal instruction, or to context switch to the program counter address of another process), and finally call mret. mret switches to the last mode that was stored in mstatus.mpp during the initial trap and then jumps to the address in mepc. Interrupt flags are also updated. mret is how M mode software transitions from M mode back to U mode (or whichever mode caused the trap).

This is a simplified explanation. There are a few more details. e.g. if the trap is delegated to S mode using medeleg/mideleg, then the processor will jump to the trap handler in stvec instead of mtvec and switch to S mode, and S mode returns to the mode that caused the trap using sret instead of mret, and the previous mode is held in sstatus.spp instead of mstatus.mpp.

Note a trap can occur in the same mode. i.e. S mode software can cause a trap and if the trap is delegated to S mode e.g. page fault, then the S mode handler in stvec is called and sret will return back to S mode. This is a horizontal trap.

You’re best bet is to read the Privileged Specification section on MRET and SRET and the section of the mstatus flags MPP, SPP, MIE, SIE, MPIE and SIE…