Changing from Kernel mode to User mode (and vice versa)

Question

I am reading Operating Systems book by Galvin. Galvin explains, what are kernel & user modes, instruction privileges given for both modes & also about mode-bit. But I am interested to know how mode changes from one to another. Basically I want to solve following question :

A CPU has 2 modes, privileged and non-privileged. In order to change the mode from previledged to non-previledged

a) A hardware interrupt is needed

b) A software interrupt is needed.

c) A privileged instruction is needed.

d) A non-privileged instruction is need.

From what I understand,

from user mode to kernel mode - Hardware Interrupt is needed [like in Disk I/O]. Now, in case user program tires to access an memory which is beyond its permissible range, a trap occurs, which is basically a software interrupt which will be handled by OS. Now, in user mode we cannot execute any privileged instructions. So, a non-privileged instruction such as I/O request can change user to kernel mode. So I think, to change

from non-privileged(user) to privileged(kernel) - H/W Interrupt, S/W Interrupt & non-Privileged instruction will do.

Now coming to, kernel to user mode. The OS can change kernel to user mode. So, it will simply run a privileged instruction to change from kernel to user mode. It does not need to generate either H/w or S/w interrupt. So I conclude, to change

from previledged to non-previledged - a privileged instruction will do.

Am I right ?

Also when executing in kernel mode, all interrupts will be disabled right ? So answer cannot be (a) or (b). Also, since OS is basically a software, it cannot generate H/W interrupts.

Also, since OS itself handles interrupts, it does not make sense to me why has to generate a interrupt (& service it) to change from kernel to user mode.

Please let me know if I am wrong anywhere. Any help regarding this is appreciated.

Answer 1

Usermode to kernelmode: Wrong! ;-) Yes, interrupts are processed in kernel mode, and originally the way to enter kernel mode was by an interrupt forced somehow by software. On the DEC 2020 there was a set of UIOs (Unimplemented Instruction Opcodes), calling any of those caused a trap to the operating system. They included floating point instructions (if not in hardware) and other exotic instructions, but also the means to do operating system calls. The i?86 family has the int (interrupt) instruction, traditionally used as you say. Newer members of the family have SYSTENT to do supervisor calls more efficiently. The means of going to supervisor mode can't be privileged, but must somehow be tightly controlled by the kernel (where you enter the kernel, what arguments you pass, ...).

Kernelmode to usermode: No need for the "drop privileges" operation to be privileged. If you don't have privileges, dropping them is a no-op. But the exact mechanism is architecture dependent in extreme.

Interrupts disabled in kernel: Interrupts indicate some condition that has to be handled as soon as possible (for example, if the data arrived over the net isn't saved from the card before the next arrives, it will get overwritten). Thus interrupts are very rarely disabled. In original Unix systems (and contemporaries), there was one CPU, and the simplest way to get a critical region ("nobody mess with my data while I modify it") was just to disable interrupts. Pains were taken to keep the "interrupt disabled" stretches as short as possible because of the above. On current multi-CPU machines, disabling interrupts on one CPU does nothing much in this direction; disabling interrupts globally is extremeñy costly in inter-CPU coordination, so it is not done (or extremely rarely).

Answer 2

From kernel(privileged) to user(unprivileged) mode , we use RtI(return from interrupt) , which is a privileged instruction (https://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.alangref/idalangref_rfi_retfinter_instrs.htm). so , according to me it should be option C.